The Controls That Fail When You Need Them Most

I was prompted to write this article after a LinkedIn post that came up recently in my feed. Picture this: your incident response plan exists. Your backup system runs every night. Your business continuity documentation sits in a shared drive, reviewed and approved. On paper, you're covered. Then, something happens. And you discover that your most important controls are the ones you've never actually used.

The Paradox of Rarely-Used Controls

There's a counterintuitive truth in security: the controls you exercise daily stay sharp, while the controls you rarely use quietly rot. Your team logs into the VPN every morning, so that process works. Your deployment pipeline runs dozens of times a week, so everyone knows the drill. But your disaster recovery procedure? Your incident response playbook? Those get written once, filed away, and forgotten until the moment they matter most.

This isn't negligence. It's human nature. When something works and you don't need to think about it, you stop thinking about it. The problem is that "working" and "ready to work when needed" aren't the same thing.

I recently worked with a client who had a documented incident response process. Detailed, approved, sitting in the right folder. When we reviewed their production incidents from the past year, we found something uncomfortable: not a single one had been documented according to that process. The incidents were fixed, the systems were restored, but the process was ignored.

When I asked why, the answer was honest: "We just forgot. We don't see that many incidents."

That's the trap. The controls you rarely use are exactly the ones most likely to drift, and exactly the ones you'll need most when things go wrong.

GitLab's $300 Million Lesson

In January 2017, GitLab.com went down. An engineer accidentally deleted the primary database while attempting to fix a replication issue. Unfortunate, but recoverable, right? That's what backups are for.

Except GitLab had five separate backup and replication mechanisms in place. None of them worked.

The automated pg_dump backups hadn't run in weeks because the backup system was configured for PostgreSQL 9.2 while GitLab was running PostgreSQL 9.6. The backup failure notifications were being sent via email, but those emails were silently rejected because of a DMARC misconfiguration. The S3 backup bucket was empty. The Azure disk snapshots weren't enabled because the team assumed the other backup methods were sufficient.

The result: 18 hours of downtime and permanent loss of 6 hours of production data. GitLab lost projects, issues, comments, and user accounts. The company live-streamed its recovery efforts on YouTube, watched by thousands. In their postmortem, they wrote what should be framed on the wall of every engineering team:

"Out of 5 backup/replication techniques deployed, none are working reliably or set up in the first place."

Why did this happen? The same reason my client's incident response process was ignored: nobody was regularly testing these systems. The backups ran in the background. The team assumed they worked. There was no ownership, no regular validation, no muscle memory.

GitLab's backup systems weren't broken by a single catastrophic event. They drifted into failure, one small change at a time, while nobody was watching.

The Controls Most Likely to Drift

At scale-ups, certain controls are almost guaranteed to drift because they're rarely exercised. Here are some examples:

• Backup restoration. Your backups run every night. When was the last time you actually restored from one? Not verified that files exist, actually restored a system and confirmed it works? Statistics suggest that 60% of backups are incomplete and 50% of restore attempts fail. The backup isn't the control. The restoration is.

• Incident response. You have a documented process for security incidents, but if incidents are rare, that process never becomes muscle memory. When a real incident happens, people revert to instinct: fix the problem first, figure out the paperwork later. The SANS Institute found that 77% of organisations don't have a formal incident response plan that's consistently applied.

• Business continuity. Your BCP exists. It was probably written to satisfy an audit requirement or close an enterprise deal. Research indicates that 41% of companies have never tested their disaster recovery systems. When was your last tabletop exercise?

• Access revocation. You have an offboarding checklist. But when someone leaves suddenly, or moves to a different team, or takes extended leave, does every system get updated? Or do orphaned accounts accumulate until someone notices during an audit?

• Vendor security reviews. You assessed your critical vendors when you onboarded them. That was three years ago. Their security posture has changed. So has yours. So has the threat landscape.

These aren't exotic edge cases. They're the standard controls that every compliance framework requires. And they're failing at company after company, not because they were never implemented, but because they were never maintained.

Why This Happens

Large enterprises have entire teams dedicated to testing controls, running tabletop exercises, and validating business continuity plans. They have the resources to build resilience as a discipline.

Early-stage startups don't need sophisticated controls because the blast radius is small. Everyone knows everyone, systems are simple, and you can rebuild from scratch if you have to.

Scale-ups are caught in between. You're big enough that a control failure could be catastrophic, but still operating with startup-era assumptions about agility and informality. You have security tools but not security processes. You have documentation but not muscle memory.

The pattern I see repeatedly: companies pass their SOC 2 audit by demonstrating that controls exist, then never actually use those controls until an auditor or an incident forces them to. The gap between "we have this control" and "this control would work if we needed it tomorrow" is where compliance breaks.

The Fix: Tabletop Exercises for Rarely-Used Controls

The solution isn't more documentation. It's practice.

A tabletop exercise is a structured walkthrough of a hypothetical scenario. You gather the relevant people, present a situation, and talk through how you'd respond. No systems get touched. No alarms go off. You're just building muscle memory and finding gaps before they matter.

The key insight is to focus your tabletop exercises specifically on rarely-used controls. Don't simulate a DDoS attack if your team deals with performance issues weekly. Simulate a data breach that requires your incident response plan. Simulate a database failure that requires backup restoration. Simulate a key employee becoming unavailable during a crisis.

Here's how to run an effective tabletop for a scale-up:

Keep it focused. Pick one scenario. A ransomware attack. A production database deletion. A critical vendor going offline. Don't try to test everything at once.

• Include the right people. This isn't just for engineers. Bring in whoever would actually be involved: your CTO, your head of customer success, someone from legal if you have one. The goal is to test coordination, not just technical response.

• Make it realistic. Use actual system names, real team members' roles, genuine third-party dependencies. The more concrete the scenario, the more useful the exercise.

• Introduce complications. Halfway through, reveal that the person who usually handles this is on vacation. Or that the backup you thought you had is corrupted. Or that a customer is demanding answers. Real incidents never follow the happy path.

• Document everything. Not to create more paperwork, but to capture the gaps you discover. Who didn't know who to call? Which process was unclear? What access did someone need but not have?

• Follow up. The exercise is worthless if you don't act on what you learned. Assign owners to fix the gaps. Schedule the next exercise.

• You don't need a full day or an external consultant. A two-hour session, run quarterly, focused on your highest-risk, rarely used controls, will do more for your actual security posture than another policy document.

The Real Test

Here's a question for every CTO reading this: if your primary database were deleted right now, could you restore it? Not "do you have backups," could you actually restore it? Do you know how long it would take? Does more than one person know how to do it? Have you tested it in the last six months?

If you're not certain, that's the control that needs a tabletop exercise next week.

Controls don't fail loudly. They drift quietly until someone measures them. The space between how a control was designed and how it actually operates is where compliance breaks, and where incidents become disasters.

The controls you use daily will keep working. The ones you don't need active investment to stay functional. Test the things you hope you'll never need, because hope isn't a strategy.

---

Paolo Carner is the founder of BARE, a cybersecurity consultancy helping scale-ups build security capabilities that actually work. He's spent 15+ years watching controls drift and helping companies catch them before auditors do.

The Security Spending Trap Episode I: Why Your Investment Isn't Protecting You

In December 2022, CircleCI—the CI/CD platform trusted by thousands of tech companies—discovered malware on an engineer's laptop. By the time they caught it, attackers had spent weeks inside their production environment, harvesting customer secrets: API keys, tokens, credentials to AWS, GitHub, and databases.

Introduction

At the time of the breach, CircleCI had everything you're supposed to have: SOC 2 Type 2 compliance, a dedicated security team, endpoint detection tools, and production monitoring. They even detected suspicious session token usage.

None of it prevented the breach. Why?

The malware bypassed their security tools. The suspicious activity blended into normal engineering noise. By the time they understood what they were looking at, attackers had exfiltrated secrets from ~4,000 customer organizations.

CircleCI's response? Force every customer to rotate every secret stored in their platform. Thousands of engineering teams spent January 2023 manually rotating credentials across their entire stack. Revenue impact for those customers: impossible to quantify. Trust impact: permanent.

The security tools were running the entire time. They just weren't protecting anyone.

The core problem

Unfortunately, security spending doesn't equal security capability. Here's the mechanism of failure that CircleCI—and likely your company—faces:

Your tools generate signals. Thousands of them. Endpoint alerts. Network anomalies. Authentication events. Each one is technically correct. Each one is potentially important. None of them contextualized.

When CircleCI's monitoring flagged suspicious session token usage, it was signal #847 that week. Was it an engineer working from a coffee shop? A CI job with weird timing? A compromised credential? The tool couldn't tell them. Someone had to investigate. But investigate how? With what priority? Using which playbook?

That gap—between "we detected something" and "we know what to do about it"—is where breaches happen.

Most scale-ups buy security tools to satisfy external requirements: SOC 2 audits, customer RFPs, and insurance applications. You implement the tool, check the box, and move on. The tool does exactly what it's designed to do: generate logs, create alerts, and produce reports for auditors.

What it doesn't do: tell you when something's actually wrong. Or what to do about it.

The illusion: "We have monitoring, so we're covered."

The reality: Monitoring without interpretation is just expensive noise.

Why this matters now

You're in the danger zone. Big enough to be worth targeting—you have valuable customer data, revenue worth disrupting, ability to pay ransom. Small enough that one incident could be existential.

Here's the asymmetry that's killing scale-ups: Your engineering team can ship a breaking change in 6 minutes. Your security posture—if you even have someone responsible for it—takes 6 hours to confirm whether an alert is real. That gap is your vulnerability.

On top of it, the external pressure is mounting. Enterprise customers are asking harder questions in vendor security reviews. Your insurance premiums are rising, or coverage is being denied outright. Your board wants proof you're managing this risk, not just spending on it.

The framework

The gap between tools and protection isn't solved by buying better tools. It's solved by building a system—five layers that work together:

1. Detection (what your tools do now)

2. Triage (what separates signal from noise)

3. Investigation (what determines actual risk)

4. Response (what contains and remediates)

5. Learning (what prevents recurrence)

Most scale-ups have Layer One. Maybe parts of layer two, if someone's writing custom detection rules, or if the technology is intelligent enough.

Layers three through five? That's where CircleCI failed. That's where you're failing.

Let me clarify: this series isn't to "teach” you another compliance framework. Not another technical standard. Over this series, I'll break down what each layer actually requires—the people, processes, and yes, tools—that make them work. But, more importantly, I'll show you why they have to work together as a system, not as disconnected point solutions.

And I am not going to tell you to rip out your existing tools. I'm going to show you what has to wrap around them to make them actually protective, rather than just performative.

---

What you'll learn

By the end of this series, you'll understand what good looks like at your scale. Not enterprise SOC scale, but not "wing it with your senior engineer" scale either. The specific capability level that matches your risk profile: too big to ignore security, too small to build a full security organization.

You'll understand the build-vs-buy calculus: what's realistic to build internally, what requires specialized expertise, and what the true cost of each option is (hint: it's not just salary).

And you'll know how to evaluate whether a provider—whether that's a consultant, a tool vendor, or a managed service—can actually deliver what you need, or if they're just selling you layer one with better marketing.

Next in this series, the second episode: "Detection Without Triage Is Just Expensive Noise" - why having alerts doesn't mean having answers.

---

Sources:

1. CircleCI Security Alert (January 4, 2023): https://circleci.com/blog/january-4-2023-security-alert/

2. CircleCI Incident Report (January 13, 2023): https://circleci.com/blog/jan-4-2023-incident-report/

3. Bleeping Computer Analysis (January 2023): https://www.bleepingcomputer.com/news/security/circleci-says-hackers-stole-encryption-keys-and-customers-secrets/

Understanding Third-Party Cyber Risk for SMBs

In September 2024, Jaguar Land Rover suffered a crippling cyberattack that temporarily halted operations. The incident was serious enough on its own, but the real story emerged when the ripple effects became visible. Over five thousand companies felt the impact of JLR's downtime, many of them small suppliers who collectively lost an estimated £1.9 billion. These suppliers weren't hacked. They weren't the target of the attack. They couldn't operate because their customer had gone dark.

Introduction

In this article, I will discuss two topics. The first one is a dimension of cyber risk that rarely gets mentioned in SMB circles, yet it represents one of the most significant operational exposures many businesses face. When we talk about cybersecurity for small and medium enterprises, the conversation typically centers on preventing direct attacks against our own systems. Hence, we discuss firewalls, employee training, backup strategies, and incident response plans. These are important, but they only address half of the risk landscape. The other half involves the uncomfortable reality that your business operations depend on vendors, suppliers, and service providers who might fail regardless of how strong your own security posture is.

The second part of this article will delve into a challenge for us SMB owners: most guidance on third-party risk management is written for enterprises with dedicated vendor management teams, comprehensive due diligence processes, and the leverage to demand security assessments from their suppliers. When you're running a business with limited resources, and you're dependent on larger vendors who won't fill out your security questionnaires, the standard advice feels simultaneously overwhelming and impractical. What you need instead is a framework that helps you understand your actual exposure, prioritize your vendor relationships intelligently, and make informed decisions about insurance and business continuity without requiring enterprise-level resources.

The Two Dimensions of Third-Party Risk

Third-party cyber risk manifests in two distinct dimensions that require different responses.

The first is the security and compliance dimension. This involves understanding what data your vendors have access to, what security controls they maintain, what contractual protections you have, and how you would respond if they experienced a breach that exposed your customer data or intellectual property. This is the dimension that compliance frameworks like ISO 27001, NIS2, and DORA address through vendor assessment requirements, contract provisions, and ongoing monitoring obligations.

The second dimension is financial risk transfer through insurance products. This addresses a different question entirely: what happens when a vendor's failure prevents you from operating, even temporarily? If your payment processor goes down for three days, you can't process customer transactions regardless of how secure your own systems are. If your cloud hosting provider experiences an outage — as recently happened with Cloudflare — your SaaS product isn't available to customers even though you did nothing wrong. If your primary component supplier gets hit with ransomware and can't fulfill orders, your manufacturing line stops. These scenarios create business interruption losses that your standard cyber insurance policy may not cover because the incident didn't happen to you directly.

Cloudflare Outage

The message users see when attempting to access your application.

Most SMBs focus exclusively on the first dimension because that's where compliance requirements and security best-practice literature point them. The insurance dimension gets less attention, partly because many business owners don't realize these products exist and partly because insurance conversations tend to happen separately from security and risk management discussions. But for resource-constrained organizations, understanding both dimensions and how they work together is essential for building practical resilience.

Understanding Contingent Business Interruption Coverage

Standard cyber insurance policies typically cover your direct losses when you're the victim of a cyberattack or systems failure. They pay for forensic investigations, legal fees, notification costs, regulatory fines, and your own business interruption losses while you recover. What they often don't automatically include is coverage for business interruption caused by incidents at your vendors or suppliers. This is where contingent business interruption coverage comes in.

Contingent business interruption coverage is designed specifically for scenarios where you can't operate because someone else in your business ecosystem has experienced a cyber incident or systems failure. The key insight is that the triggering event doesn't have to be a security incident in the traditional sense. An unintentional systems outage at a critical vendor triggers this coverage just as much as a ransomware attack would. The coverage focuses on the business interruption impact to you rather than the cause of the incident at the vendor.

The challenge is that many SMB owners don't realize this coverage exists as a separate component that may need to be explicitly added to their cyber insurance policy. They assume their cyber insurance covers all scenarios where technology failures disrupt their business, but that assumption is often wrong. This creates a silent gap in their risk management strategy where they've invested in security controls and purchased insurance, but still have significant uninsured exposure to vendor failures.

When you're evaluating whether you need this coverage and at what limits, you need to understand which vendor failures would actually create material business interruption losses for your organization. This is where the business impact analysis framework becomes essential, because it helps you move from abstract vendor risk to concrete financial exposure.

You can read more about this here.

Simplified Business Impact Analysis

Enterprise business impact analysis frameworks are comprehensive but often overwhelming for SMBs. They involve mapping every business process, calculating precise recovery time objectives, estimating financial impacts with actuarial precision, and maintaining detailed documentation that requires dedicated resources to keep current. However, what SMB owners often need is something simpler that still provides enough insight to make intelligent decisions about vendor risk priorities and insurance coverage.

Identifying Key Business Processes

The simplified approach starts by identifying your core business processes. These are not every process your organization performs, but specifically the ones that directly generate revenue or fulfill your core value proposition to customers. For a SaaS company, this might include customer acquisition, product delivery, customer support, and billing. For a professional services firm, it might be project delivery, client communication, invoicing, and knowledge management. For a manufacturer, it could be order intake, production, quality control, logistics, and customer service. The key here is to limit yourself to five to seven core processes at most, because you want this exercise to be completed in a few hours rather than become a months-long documentation project.

For each core process you've identified, you need to answer two fundamental questions.

First, how long could this process go on before you start experiencing significant harm to your business? This doesn't require precision down to the hour. Categories like "hours," "one to two days," "three to five days," or "a week or more" are sufficient for this exercise. What you're establishing is a practical understanding of time sensitivity. Some processes are so critical that even a few hours of downtime creates significant problems. Others might be inconvenient if down for a day, but only become serious business issues after several days.

The second question is what would actually happen if this process stopped for that length of time. Think concretely about the consequences in terms of lost revenue, customer churn, contractual penalties, regulatory fines, reputational damage, or additional costs you'd incur trying to work around the outage. Again, rough magnitude is more valuable than false precision. Understanding that a particular outage would cost you thousands, tens of thousands, or hundreds of thousands of euros is sufficient to prioritize your risk management efforts appropriately.

You can download a ready-to-use BIA template here.

Connecting the Dots

Once you understand your critical processes and their time sensitivity, you trace each one back to its dependencies. For each critical process, identify which vendors, suppliers, or service providers would cause that process to fail if they experienced an outage. This is where abstract vendor risk becomes concrete operational exposure. Your ability to process customer payments depends on your payment processor. Your product delivery depends on your cloud infrastructure provider. Your customer support depends on your helpdesk platform. Your manufacturing depends on specific component suppliers. Your professional services delivery might depend on collaboration platforms or specialized software tools.

The insight that often emerges from this exercise is the discovery of single points of failure you hadn't fully appreciated. You might realize that one SaaS vendor supports three core processes, so an outage would cascade across your entire operation. You might discover that you have no practical backup for a critical service because you've optimized for cost or convenience rather than resilience. You might find that your most time-sensitive processes depend on vendors you've never assessed for reliability or business continuity.

This isn't about creating paranoia or suggesting you need redundancy for everything. Resources are limited, and some single points of failure are acceptable risks when the cost of mitigation exceeds the realistic exposure. What this framework provides is informed decision-making about where redundancy matters, where you need contractual protections, where insurance coverage is most valuable, and where your incident response planning needs to focus.

What Good Enough Vendor Management Looks Like for SMBs

The gap between enterprise vendor risk management guidance and SMB reality is substantial. Enterprise frameworks assume you can require security assessments from vendors, that you can walk away from vendors who don't meet your standards, and that you have dedicated teams to monitor vendor performance and compliance. SMBs face different constraints:

• You're often dependent on large SaaS providers that won't complete your security questionnaires.

• You may have limited alternatives for critical suppliers.

• You're managing vendor relationships as one of many responsibilities rather than as a full-time role.

What good enough looks like in this context starts with focus. Rather than attempting to assess all vendors equally, you concentrate your efforts on the critical dependencies you identified through your business impact analysis. For those vendors, you document what they do, why they're crucial, what data they access, and what alternatives exist if they fail. This documentation doesn't need to be elaborate, but it should be sufficient that someone else in your organization could understand the dependency and begin working on a workaround if needed.

For critical vendors, you ask basic but essential questions even if you can't require comprehensive security assessments:

• Do they carry cyber insurance themselves?

• What business continuity and disaster recovery capabilities do they maintain?

• What are their committed uptime targets, and what remedies are in place if they fail to meet them?

• Have they experienced significant outages or security incidents in the past, and how did they handle them?

These questions don't require the vendor to complete lengthy questionnaires, but the answers provide helpful insight into their reliability and how they think about risk.

Your contracts with critical vendors should include provisions that protect your interests when things go wrong. This includes clear service-level agreements with meaningful remedies for failures, liability provisions that don't completely absolve the vendor of responsibility, termination rights that give you an exit if performance degrades, and, ideally, some business continuity commitments about how they'll maintain operations during disruptions. Many SMBs sign vendor contracts without negotiating these terms because they assume they lack leverage. Still, even large vendors will often accept reasonable protective provisions if you ask for them during contract negotiations.

Where you cannot genuinely assess or influence a vendor's practices because of your size or their market position, you shift your focus to your own resilience. This means having documented workarounds or alternatives, even if they're not ideal, maintaining your own backups of critical data rather than relying solely on vendor backup promises, and building operational flexibility that reduces your dependence on any single vendor.

BIA and Insurance Decisions

So, you might wonder, how are these two topics related? The business impact analysis directly informs your insurance coverage decisions in ways that general risk advice cannot. When you've identified that your payment processing going down for three days would cost you fifty thousand euros in lost revenue and potentially cause customer churn, you now have concrete information to evaluate whether contingent business interruption coverage makes financial sense. The insurance premium needs to be weighed against a specific, quantified exposure rather than an abstract fear of vendor failures.

Similarly, when you've mapped your critical vendor dependencies, you can have more intelligent conversations with your insurance broker about what scenarios your policy should cover. If you're primarily concerned about your cloud infrastructure provider, that's a different coverage discussion than if your main exposure is to component suppliers or professional service providers. The policy terms around what constitutes a covered event, what documentation you need to file a claim, and what waiting periods apply all matter more when you understand your actual dependencies.

Your vendor due diligence practices also affect your insurability in ways many SMB owners don't realize. When insurance carriers ask about your vendor management procedures during underwriting, they're assessing whether you understand your critical dependencies and whether you've taken reasonable steps to manage them. They're not expecting enterprise-level vendor assessment programs. Still, they do want to see that you know which vendors matter, that you've asked basic questions about their reliability and business continuity capabilities, that you have some contractual protections in place, and that you've thought about alternatives or workarounds if a critical vendor fails.

This creates a reinforcing cycle where good vendor risk management makes you more insurable at better rates, and the insurance coverage provides financial protection for the residual risk you can't eliminate through vendor management alone. For SMBs operating with constrained resources, this combination of selective vendor management focused on critical dependencies plus appropriate insurance coverage is often more practical than attempting to prevent all possible vendor failures through exhaustive due diligence.

Connecting to Compliance Frameworks

Finally, if you're pursuing ISO 27001 certification, working toward NIS2 compliance, or subject to DORA requirements, your vendor risk management efforts serve double duty. These frameworks all include explicit requirements for managing third-party risks, assessing supplier relationships, and maintaining business continuity capabilities. The simplified BIA framework and vendor management practices we've discussed aren't additional work on top of compliance requirements—they're practical implementations of those requirements that also happen to inform your insurance decisions and improve your actual operational resilience.

ISO 27001 requires supplier relationship management through controls that address supplier security assessment, contract provisions, and ongoing monitoring. The business impact analysis you conduct to understand your critical vendor dependencies directly supports your ISO 27001 business continuity planning requirements. You're creating the same documentation and conducting the same analysis, but applying it to both compliance and insurance risk management purposes.

NIS2 applies to a broader range of organizations and includes specific requirements for identifying critical functions, managing supply chain risk, and ensuring business continuity. The framework for identifying critical business processes and their vendor dependencies addresses these requirements while simultaneously helping you understand where contingent business interruption coverage would be most valuable.

DORA is particularly explicit about third-party risk management for financial entities, requiring ICT third-party risk monitoring, contract provisions, and concentration risk management. The same vendor assessment and dependency mapping that helps you comply with DORA also informs your decisions about insurance coverage and business continuity planning.

The point is that good vendor risk management isn't separate from compliance work. When done thoughtfully, your vendor risk management program simultaneously addresses regulatory requirements, informs insurance decisions, and improves your actual ability to maintain operations when vendors fail. For resource-constrained SMBs, finding these synergies between different risk management objectives is essential for getting meaningful risk reduction without unsustainable resource commitments.

Practical Next Steps

Moving from understanding third-party risk to actually managing it requires concrete actions that fit within your operational constraints.

The first step is conducting the simplified business impact analysis we've discussed. Block out two to three hours, gather the people in your organization who understand your operations, and systematically work through identifying your core business processes, their time sensitivity, and their critical vendor dependencies. Create simple documentation of this analysis—a spreadsheet or table is sufficient—that captures what you've learned about your operational dependencies.

Once you understand your critical vendor dependencies, the second step is reviewing your current cyber insurance policy specifically through the lens of third-party risk. Pull out your policy documents or contact your broker and explicitly ask whether you have contingent business interruption coverage. If you have it, understand what it covers, what limits apply, what documentation would be required to file a claim, and whether any waiting periods apply. If you don't have it, ask your broker to explain what it would cost to add this coverage and at what limits it's available. Come to this conversation armed with the information from your business impact analysis about which vendor failures would create significant business interruption costs.

The third step involves addressing the gaps your analysis revealed. For your most critical vendor dependencies, review the contractual protections in place, the alternatives available if that vendor fails, and whether you need to make changes to reduce your risk. This doesn't mean you need to replace vendors or build redundancy for everything immediately. Still, you should consciously decide which risks you're accepting, which ones you're mitigating, and which ones you're transferring through insurance or contracts.

Finally, incorporate your vendor dependency information into your incident response planning. Make sure the people who would need to respond to a vendor outage know your critical dependencies, have contact information for key vendors, understand available alternatives, and know how to access your insurance coverage if needed. The most complicated incident responses happen when there's a disconnect between who knows about the response plan and who needs to execute it. For SMBs, this often means ensuring that your IT person, your operations leader, and whoever handles insurance and risk management are all working from the same understanding of vendor dependencies and response procedures.

Moving Forward

Third-party cyber risk isn't new, but it's becoming harder to ignore as business ecosystems become more interconnected and dependencies more critical. The JLR incident reminded us that cyber incidents don't respect organizational boundaries, and the financial impact of vendor failures can be just as severe as direct attacks. For SMBs operating with limited resources and significant dependencies on vendors they can't fully control, the combination of focused vendor management, appropriate insurance coverage, and practical business continuity planning provides realistic resilience without requiring enterprise-level programs.

The key is to move from abstract awareness of vendor risk to a concrete understanding of which vendor failures would actually harm your business and what you can do about them. The simplified business impact analysis gives you that concrete understanding. The insurance discussion with your broker provides a financial risk-transfer option for the residual risk you can't eliminate. The vendor management practices we've discussed give you practical ways to reduce risk within your resource constraints. Together, these elements create a vendor risk management approach that's realistic for SMBs while still providing meaningful protection.

---

Download your ready-to-use BIA template here. If you'd like help conducting a business impact analysis for your organization or reviewing your vendor risk management practices, I'm happy to discuss how we can approach this work in ways that serve both your compliance requirements and your practical business resilience needs.

Why Your Fintech Customers are Reworking Your SaaS Contract (and What You Need to Fix Now)

The Email That Changed Everything

Let me guess: you've recently received an email from one of your fintech clients. Maybe it was from their legal team, or perhaps their Chief Compliance Officer. The subject line probably read something like "Urgent: Contract Amendment Required" or "DORA Compliance Requirements - Action Needed."

Your stomach might have sunk a little as you opened it. Inside? A laundry list of new contract clauses, information requests you've never seen before, and terminology that feels like it came from a different universe. Terms like "ICT Third-Party Service Provider," "Critical or Important Functions," and "Threat-Led Penetration Testing."

Welcome to the new world of DORA compliance. And if you're reading this, you're already ahead of the curve.

Why This Matters (And Why It's Not Going Away)

If your SaaS company serves fintechs, banks, insurance firms, or any financial institution operating in the EU, you're not experiencing a temporary phase or a passing trend. You're witnessing a fundamental, permanent shift in how the European Union regulates digital operational resilience in the financial sector.

The EU Digital Operational Resilience Act (DORA) isn't a suggestion. It's a mandatory law that has been in effect since January 17, 2025.

Think of DORA as the EU's response to a simple but critical question: "What happens when the financial system's digital backbone fails?" After years of increasing cyber incidents, cloud outages, and third-party failures that cascaded through the financial sector, European regulators decided that hoping for the best was no longer an acceptable strategy.

The result? One of the most comprehensive operational resilience frameworks ever created for the financial sector. And here's the kicker: it doesn't just regulate banks and fintechs—it reaches directly through to you, their technology provider.

Understanding Your New Role: From Vendor to Regulated Partner

Here's what's changed at a fundamental level:

Before DORA: You were a vendor. Your customer was… well, a customer. You had a commercial contract focused on service delivery, pricing, and basic legal protections. As long as you delivered what you promised, everyone was happy.

After DORA: You're now classified as an "ICT Third-Party Service Provider" (ICT TPP). Your customer isn't just a customer anymore—they're a "Financial Entity" (FE) with legal obligations that flow directly through to you. Your contract isn't just a commercial agreement; it's now a compliance instrument that must meet the requirements of EU financial regulators.

Your fintech customer, as the regulated Financial Entity, remains fully and ultimately responsible for complying with all DORA obligations—even for the parts of their operations that rely entirely on your SaaS platform.

Yes. Read that again: they're on the hook for your performance.

That's why they're knocking on your door. It's not that they don't trust you. It's that their regulator doesn't accept "but our vendor handles that" as an excuse for non-compliance.

Why Your Existing Contract Just Became a Compliance Liability

Let's be honest: your current contract probably wasn't written with EU financial regulation in mind. Why would it be? You're a SaaS company, not a bank.

But here's the uncomfortable truth: your customers are facing the reality that their existing contracts with you might actually create regulatory risk rather than manage it.

Your standard contract probably has:

• Vague service descriptions ("platform access and support")

• Generic liability caps that don't account for regulatory incidents

• Limited transparency requirements around your operations

• Minimal audit rights (if any)

• Standard termination clauses are designed for mutual convenience, not regulatory emergencies.

Under DORA, each of these represents a potential compliance failure for your customer. Their contract with you needs to shift from a commercial agreement to a comprehensive tool for managing digital operational resilience and risk control across the entire service lifecycle—from initial onboarding to emergency exit scenarios.

The Core Mandate: What DORA Actually Requires

DORA mandates specific provisions that must be included in every contract between a Financial Entity and an ICT Third-Party Service Provider. Not "should include" or "best practice to include"—must consist of. Without these clauses, your customer faces regulatory scrutiny, potential supervisory fines, and in extreme cases, restrictions on their ability to operate.

Let me break down what you need to deliver, organized by complexity and urgency.

Tier 1: The Foundation (Applies to Every Service Contract)

These requirements apply regardless of whether you're providing a simple marketing automation tool or running core transaction processing. Every SaaS provider serving EU financial institutions needs to address these basics:

1. Crystal-Clear Service Scope and Subcontracting Transparency

What your customer needs: A precise, unambiguous description of exactly what services you provide. Not marketing copy—actual, technical detail about what your platform does, what data it processes, and what functions it performs.

The subcontracting piece: You must explicitly state whether you use subcontractors (spoiler: if you use AWS, Google Cloud, or any third-party service, the answer is yes). If you do, you need to detail:

• Who your critical subcontractors are

• What they do

• Where they're located

• Under what conditions might you add or change subcontractors.

Why it matters: Your customer can't manage supply chain risk if they don't know their supply chain. Every subcontractor you add represents a potential point of failure in their operational resilience framework. DORA demands they know—and approve—these dependencies upfront.

Real-world example: Imagine you use a third-party email service to send transaction notifications to end users. That email service has an outage. Your customer's end users can't receive critical account alerts. Under DORA, your customer's regulator will ask: "Did you know this dependency existed? Did you assess the risk? Did you have a backup plan?" If the answer is no, that's a compliance failure.

2. Data and Service Location (And the Obligation to Alert Before Changes)

What your customer needs: Specific information about where—geographically—your services operate and where their data is stored. Not just "the cloud" or "EU region," but actual countries or specific data centers.

The change notification piece: You must commit to notifying your customer in advance of any planned changes to these locations. Not after the fact, not as a courtesy—before it happens, with enough time for them to assess the risk and potentially object.

Why it matters: Data location affects three critical compliance areas:

1. Jurisdiction and legal risk: Different countries have different legal frameworks, seizure risks, and government access laws

2. Data protection compliance: GDPR and local data protection laws vary by location

3. Geopolitical risk: Political instability, sanctions, or diplomatic tensions can suddenly make a previously safe location problematic.

Real-world example: You decide to expand operations to a new AWS region to improve performance. That new region is in a country that recently underwent significant changes to data access laws. Your customer's regulator flags this as an unacceptable jurisdiction risk. If you didn't notify them in advance, your customer has just failed their DORA obligation to maintain control over ICT arrangement risks.

3. Incident Assistance (Pre-Agreed and Pre-Priced)

What your customer needs: A contractual obligation from you to assist with any ICT incident related to your service. And critically, the cost for this assistance must be determined in advance—before an incident occurs.

Why it matters: Under DORA, Financial Entities have strict regulatory reporting timelines when incidents occur. We're talking about hours, not days. Major incidents might need to be reported to authorities within 4 hours of detection.

Your customer cannot afford to be in a position where:

• They're unsure whether you'll help

• They need to negotiate billing rates while their systems are down

• You're offering "premium support" as an upsell during an emergency.

Real-world example: It's 3 AM on a Saturday. Your platform experiences a security incident that affects your customers' ability to process payments. Their compliance team needs detailed incident logs, your security team's assessment, and technical support to implement temporary workarounds—all within hours to meet regulatory reporting deadlines. If your contract doesn't obligate you to provide this support immediately (and if they're worried about surprise invoices), they're in regulatory hot water before the technical problem is even solved.

4. Data Access, Recovery, and Return Rights

What your customer needs: Cast-iron guarantees that they can access, recover, and ultimately retrieve all their data in a usable, easily accessible format. And these guarantees must hold true even if you go bankrupt, shut down your business, or discontinue your service.

Why it matters: Business continuity can't depend on your financial health. Your customer needs assurance that even if your startup fails spectacularly, their data (and their business operations) won't go down with it.

The format matters: "Easily accessible format" means your customer shouldn't need specialized tools, proprietary software, or arcane technical knowledge to use their data once they get it back. Standard formats (JSON, CSV, SQL dumps) are expected.

Real-world example: Your well-funded competitor acquires you. As part of the acquisition, they decided to sunset your product line. Your customers have 90 days to migrate. Under DORA, you're obligated to provide complete data export capabilities in a format that works with their (likely different) new provider. No "data export fees," no "premium migration support package"—this is a fundamental right.

5. Regulatory Access and Cooperation

What your customer needs: Your explicit, contractual agreement to cooperate fully with:

• Your customer's regulatory authorities (called "Competent Authorities" or CAs in DORA-speak)

• Resolution authorities (who step in if your customer fails)

• Any investigation, inquiry, or audit that these authorities request.

Why it matters: EU financial regulators have a firm principle: if you're part of the regulated entity's operations, you're within their supervisory perimeter. They need to be able to inspect, question, and audit any party that could affect the Financial Entity's operational resilience—including you.

What this means practically: If a regulator shows up (virtually or in person) to ask questions about your infrastructure, security controls, or incident response, you can't hide behind "proprietary information" or "commercial confidentiality." You need to cooperate, provide information, and allow access.

Real-world example: Your customer undergoes a DORA supervisory review. The regulator identifies your service as a potential concentration risk (many of the regulator's supervised entities use you). They request detailed information on your business continuity plans, financial stability, and incident history. You must provide it. Your contract needs to make this explicit.

6. Financial Entity Termination Rights (Even When It's Not Your Fault)

What your customer needs: Explicit, unambiguous rights to terminate the contract immediately in specific scenarios:

• You've significantly breached applicable laws or regulations

• You've materially breached the contract

• The regulatory authority determines that it can no longer effectively supervise your customer under your arrangement.

The uncomfortable part: That last bullet point means your customer might need to terminate even if you haven't done anything wrong. If the regulator decides your arrangement creates supervisory risk, your customer needs a legal exit ramp.

Why it matters: Regulatory compliance sometimes requires speed. Your customer can't be locked into a contract that prevents them from eliminating regulatory risk immediately, even if it's inconvenient or commercially unfavorable for you.

Real-world example: A regulator conducts a thematic review of cloud concentration risk and determines that too many Financial Entities rely on your specific infrastructure provider. They require your customer to diversify. Your customer needs to terminate or significantly modify your agreement not because you failed, but because the regulatory landscape changed. Your contract needs to accommodate this.

Tier 2: High-Impact Demands for Critical Services

Now we get to the requirements that are probably causing the most friction in your contract negotiations. These apply specifically when your SaaS platform supports a "Critical or Important Function" (or CIF, in DORA's lingo) for your customer.

What's a Critical or Important Function? Think of it as any business function that, if disrupted, would:

• Materially harm the Financial Entity's business

• Damage their reputation

• Cause financial loss to the entity or its customers

• Breach regulatory obligations

Examples include: payment processing, customer authentication, transaction monitoring, core banking operations, trading platforms, or risk management systems.

If your platform touches any of these areas, buckle up. The requirements intensify significantly.

1. Performance Transparency Through Measurable KPIs

What your customer needs: Detailed Service Level Descriptions (not just basic SLAs) with precise, quantitative, and qualitative performance targets. We're talking about granular Key Performance Indicators (KPIs) that can be measured, tracked, and reported to regulators.

The death of generic SLAs: Your standard "99.9% uptime" SLA isn't enough anymore. Regulators want to see metrics like:

• Specific response time percentiles (P50, P95, P99) for critical operations

• Error rates by transaction type

• Time to detect and time to resolve for different incident severities

• Data processing latency metrics

• Availability measurements at a feature level, not just at the platform level.

Why it matters: Your customer needs to prove to their regulator that they have adequate controls over their ICT third-party risk. Generic promises don't demonstrate control—measurable outcomes do. If they can't show KPIs that prove your service meets their operational resilience requirements, they fail their DORA obligations.

Real-world example: Your platform processes payment authorizations. A generic "99.9% uptime" SLA tells regulators nothing about whether the platform can handle peak transaction volumes during critical periods (like holiday shopping) or how quickly it recovers from partial failures. Your customer needs metrics that prove: "Authorization requests complete in under 500ms for 99% of transactions, even during peak load, and degraded service is restored to full capacity within 15 minutes of detection."

2. Audit and Inspection Rights (The Biggest Challenge for SaaS)

What your customer needs: To grant audit and inspection rights to:

• The Financial Entity itself

• An independent third party they appoint

• Their Competent Authority (regulator).

And here's the kicker: these need to be unrestricted rights of access, inspection, and audit.

Why this is the biggest hurdle for SaaS companies: If you serve 100 financial institutions, you could theoretically face 100+ individual audit requests per year, each with different scope, timing, and methodologies. This is operationally impossible for most startups.

The practical solution: DORA recognizes this problem. You have two main paths to satisfy audit requirements:

1. Pooled Audits: Multiple customers share a single audit. You coordinate one comprehensive audit that meets the needs of many Financial Entity customers simultaneously. This requires careful planning, a standardized scope, and agreement from all participating customers.

2. Independent Assurance Reports: You obtain recognized, independent third-party assurance reports (like SOC 2 Type 2, ISO 27001, or other relevant certifications) and make these readily available to your customers under appropriate confidentiality agreements.

What you must provide: Clear contractual terms that define:

• How audit rights will be exercised (pooled audits vs. independent reports)

• The process for accessing assurance information

• Timelines for providing audit evidence

• Cost allocation (if any) for audit activities

• Your commitment to remediate any findings within agreed timeframes.

Real-world example: You undergo an annual SOC 2 Type 2 audit covering security, availability, and confidentiality. You make this report available to all Financial Entity customers under NDA within 30 days of report issuance. Your contract explicitly states that this report satisfies the standard audit requirements, but customers retain the right to request specific additional audits if they identify gaps in the SOC 2 scope. This balances your operational constraints with their regulatory obligations.

3. Business Continuity and Resilience Testing

What your customer needs: Your active cooperation in their digital operational resilience testing program, including:

• Participation in scenario-based testing

• Support for Threat-Led Penetration Testing (TLPT)—basically, sophisticated simulated attacks on your infrastructure

• Regular testing of your own business continuity plans

• Evidence that your disaster recovery capabilities actually work.

Why it matters: Under DORA, resilience isn't assumed or promised—it must be proven through testing. Your customer is required to conduct regular operational resilience testing, and if your service is critical to their operations, you're part of that testing program.

What "cooperation" means practically:

• Allowing controlled testing activities against your production or dedicated test environments

• Providing technical resources to support testing scenarios

• Sharing results of your own internal resilience testing

• Participating in post-test analysis and remediation planning.

The TLPT requirement: For the most critical services, your customer might need to conduct (or participate in) advanced Threat-Led Penetration Testing. This isn't a basic vulnerability scan—it's sophisticated, red-team style testing that simulates real-world attack scenarios. If your service is in scope, you need to contractually commit to supporting this level of testing.

Real-world example: Your customer conducts quarterly business continuity tests where they simulate various failure scenarios. One quarter, they test: "What happens if our primary payment processor (you) experiences a complete regional outage?" Your contract obligates you to:

• Provide technical details about your failover architecture

• Participate in the test by activating your documented failover procedures

• Allow them to verify that the failover actually works as designed

• Document lessons learned and implement improvements.

4. Exit Strategy and Transition Support (The "Plan B" You Hoped They'd Never Need)

What your customer needs: Your explicit commitment to support their documented Exit Plan. This includes:

• Offering an adequate transition period to migrate to another provider or an in-house solution

• The length of this transition period is often dictated by regulators based on the criticality of the function

• Detailed technical and operational support during the transition

• Clear terms about data portability, system integration support, and knowledge transfer.

Why it matters: Your customer is legally required to have a tested, documented "Plan B" for every critical ICT service they rely on. This isn't just a theoretical document—regulators expect these exit plans to be realistic, detailed, and regularly tested.

The uncomfortable reality: Your contract needs to contemplate scenarios where:

• You go out of business suddenly

• Your service quality degrades unacceptably

• Regulatory requirements force a change

• Commercial terms can't be agreed upon for renewal

• A competitor acquires your business

• Strategic changes make your service non-viable.

What you must commit to: Even in adverse scenarios (like insolvency), you need to define:

• Minimum transition period (often 3-12 months for critical functions)

• What support you provide during transition (technical documentation, training, integration assistance)

• Data extraction processes and formats

• How will ongoing service levels be maintained during the transition

• Cost structure for transition support.

Real-world example: Your customer's Exit Plan states: "In the event of service termination, Provider will offer a minimum 6-month transition period with continued service at existing SLA levels, provide complete technical documentation, assign a dedicated transition support engineer, and deliver all data in standardized formats within 30 days of termination notice." Your contract needs to make these commitments explicit and enforceable.

The Oversight Framework: When DORA Reaches Directly to You

Here's something many SaaS providers don't realize yet: depending on your size and criticality, you might become directly supervised by EU financial regulators.

DORA introduces a new oversight framework for "Critical Third-Party Service Providers" (CTPPs). If you're designated as a CTPP, you're no longer just subject to contractual obligations with your customers—EU authorities directly regulate you.

How do you become a CTPP? The designation considers factors like:

• The number of Financial Entities that rely on you

• The systemic importance of the functions you support

• Whether there are readily available alternatives to your service

• Your interconnectedness with the broader financial system

What does it mean if you're designated? Direct oversight, including:

• Regular reporting to EU authorities

• On-site inspections of your operations

• Recommendations or requirements to address identified risks

• Potential financial penalties for non-compliance

Why this matters for your contract negotiations: Even if you're not currently a CTPP, the possibility of future designation should inform how you structure your compliance approach now. Building strong DORA compliance practices today makes the potential future designation less disruptive.

Strategic Responses: How to Turn DORA from Threat to Advantage

I know what you're thinking: "This sounds expensive, time-consuming, and operationally complex. Why wouldn't we exit the EU financial services market?"

Here's why you shouldn't panic, and why embracing DORA might be your best strategic move:

1. First-Mover Advantage Is Real

Right now, most of your competitors are either:

• Panicking and making short-term reactive decisions

• Ignoring DORA entirely (which will cost them customers)

• Trying to minimize compliance efforts (which will create trust issues)

By proactively embracing DORA compliance, you become the trusted choice for risk-conscious financial institutions. Your competitors' compliance problems become your sales advantage.

2. DORA Compliance Signals Maturity

Financial institutions are increasingly wary of working with startups that might disappear, pivot, or fail unexpectedly. By demonstrating that you:

• Understand complex regulatory requirements

• Can document and test your resilience capabilities

• Have thought through business continuity and exit scenarios

• Welcome oversight and transparency

You're essentially saying: "We're not a risky startup—we're a reliable partner that operates like an enterprise, even if we're still growing."

3. The Investment Pays Off Beyond EU Financial Services

Many DORA requirements align with best practices for operational resilience generally:

• Strong business continuity planning

• Comprehensive vendor management

• Incident response capabilities

• Regular security testing

• Documented audit trails

Investing in DORA compliance makes you more attractive to any enterprise customer in any regulated industry, not just EU financial services.

Practical Action Plan: What to Do Right Now

Let's get tactical. Here's your roadmap for navigating DORA effectively:

Immediate Actions (This Month)

1. Assess Your Exposure

• Create a list of all customers who are (or might be) Financial Entities under DORA

• Identify which services you provide that might support Critical or Important Functions

• Prioritize based on contract value and strategic importance

2. Review Your Current Contracts

• Pull your standard contracts and compare them against the mandatory clauses outlined above

• Identify gaps (you'll find many)

• Document which customers have which contract versions

3. Start Internal Documentation

• Map your subcontractor relationships (every single one)

• Document current data and service locations

• Review and update your incident response procedures

• Assess the current state of your business continuity plans

Short-Term Actions (Next 90 Days)

1. Develop DORA-Compliant Contract Templates. Work with legal counsel who understands both SaaS and EU financial regulation to create:

• Standard DORA Addendum that can be attached to existing contracts

• Updated standard terms for new contracts

• Flexible frameworks for the high-impact requirements (especially audit rights)

2. Build Your Transparency Documentation Package. Create a standardized information package that you can provide to any Financial Entity customer:

• Service description and architecture overview (non-confidential version)

• Subcontractor list with key details

• Data location and processing information

• Current security certifications and audit reports

• Incident response and support procedures

• Business continuity and disaster recovery summaries

3. Evaluate Assurance Strategy. Decide whether you'll pursue:

• SOC 2 Type 2 certification (often the baseline for SaaS)

• ISO 27001 certification

• Additional industry-specific certifications

• Custom audit frameworks

Get quotes, understand timelines, and budget appropriately.

Medium-Term Actions (Next 6-12 Months)

1. Implement Systematic Contract Updates

• Start with customers who have identified your service as critical

• Use your standard DORA Addendum to streamline negotiations

• Set internal targets for the percentage of DORA-compliant contracts

2. Enhance Operational Capabilities

• Formalize your business continuity and disaster recovery testing schedule

• Implement KPI tracking systems that can generate the metrics customers need

• Develop customer-facing resilience reporting (quarterly or annual summaries)

• Build out exit and transition planning frameworks

3. Create Customer Enablement Resources. Help your customers help themselves:

• Self-service portal for accessing compliance documentation

• Templates for exit planning

• Clear escalation paths for incidents and regulatory inquiries

• Regular "state of resilience" communications

Long-Term Strategic Positioning

1. Make Compliance a Market Differentiator

• Highlight your DORA readiness in sales materials

• Train your sales team on how to discuss operational resilience

• Create case studies showing how you've successfully supported customers' DORA compliance

2. Build Compliance into Product Development

• Include resilience requirements in your product roadmap

• Design with auditability and transparency in mind

• Consider building customer-facing resilience dashboards

3. Foster Industry Collaboration

• Participate in industry working groups on DORA implementation

• Share learnings (within legal bounds) with other SaaS providers

• Consider forming pooled audit arrangements with complementary providers

Common Pitfalls to Avoid

As you navigate DORA compliance, watch out for these common mistakes:

Pitfall #1: The "One Size Fits All" Approach

Not all your customers have the exact DORA requirements. A small fintech startup might classify your service as non-critical, while a major bank considers it essential. Trying to force identical terms on everyone wastes time and creates friction.

Instead: Develop tiered approaches based on criticality and customer size.

Pitfall #2: Treating DORA as Purely a Legal Exercise

Your legal team can draft compliant contract language, but DORA compliance requires operational capability. You can't contract your way out of operational deficiencies.

Instead, ensure your legal, technical, and operational teams work together. Compliance is cross-functional.

Pitfall #3: Waiting for Customers to Define Requirements

Many of your customers are still figuring out their own DORA obligations. If you wait for them to tell you exactly what they need, you'll be perpetually reactive and negotiations will drag on forever.

Instead, be proactive—present solutions rather than waiting for problems to be defined.

Pitfall #4: Underestimating Negotiation Time

DORA contract negotiations are not quick wins. Financial institutions' legal and compliance teams move deliberately, especially when dealing with novel regulatory requirements.

Instead, start early, budget significant time, and build strong relationships with customer stakeholders beyond just procurement.

Pitfall #5: Ignoring the Subcontractor Chain

You might be DORA-ready, but what about your infrastructure providers, your payment processor, your authentication service? Your customers' DORA obligations don't stop at your front door—they flow through your entire supply chain.

Instead, assess your own supply chain and proactively address dependencies that pose risks to your customers.

DORA Is Your Reality Now

If you're still reading this far, you're clearly taking DORA seriously. Good. You should.

Here's what I want you to take away:

DORA is not temporary. It's not going away. It's not something you can wait out or avoid if you want to serve EU financial services markets.

DORA is not optional. Your customers don't have a choice about compliance. By extension, neither do you if you want to keep them.

DORA is not just a burden. Yes, it requires investment and operational changes. But it's also an opportunity to differentiate yourself, to demonstrate maturity, and to build deeper, more strategic relationships with your most important customers.

The SaaS providers who thrive in the post-DORA world won't be the ones with the most clever legal workarounds or the ones who managed to minimize their compliance obligations. They'll be the ones who embraced operational resilience as a core value proposition and made transparency a competitive advantage.

Your customers are knocking on your door because they need your help to comply with DORA. This is your chance to show them you're a partner they can rely on—not just today, but through the next regulatory change, the next crisis, and the next evolution of their business.

The question isn't whether you'll comply with DORA. The question is: will you be reactive and grudging, or strategic and proactive?

I know which approach builds better businesses.

Now get to work.

---

Additional Resources

• Official DORA Text: EUR-Lex

• European Banking Authority (EBA) DORA Guidelines: EBA Website

A Practical Guide to Cybersecurity Spending for SMBs in 2025

Introduction

Small and medium-sized businesses (SMBs) are the backbone of the European economy, but their increasing reliance on digital technologies has made them a prime target for cybercriminals. With cyberattacks growing in sophistication and frequency, the question for SMBs is no longer if they will be targeted, but when. A staggering 31% of SMBs have already fallen victim to cyberattacks, facing average costs of €250,000 and, in some cases, as high as €7 million [1].

This article provides a comprehensive guide for European SMBs to navigate the complex landscape of cybersecurity spending in 2025. We will explore recommended budget benchmarks, effective allocation strategies, and the significant impact of new regulations, such as the NIS2 Directive. By understanding these key considerations, SMBs can build a robust defense against cyber threats and ensure their long-term resilience.

The Escalating Threat Landscape

The digital world is a double-edged sword. While it offers unprecedented opportunities for growth and innovation, it also exposes businesses to a host of cyber threats. The rise of artificial intelligence (AI) has further complicated the situation, with 83% of SMBs believing that AI has increased the cybersecurity threat level [2]. Cybercriminals are now leveraging AI to launch more sophisticated and scalable attacks, making it increasingly difficult for businesses to defend themselves.

Losses by Threat Type

This table summarizes the most common and costly cyber threats facing SMBs today

These statistics paint a grim picture, with 61% of SMBs now fearing that a single serious cyberattack could put them out of business [2]. This highlights the crucial need for a proactive and adequately funded cybersecurity strategy.

Recommended Cybersecurity Spending for SMBs

Determining the right amount to invest in cybersecurity can be a daunting task for SMBs. While there is no one-size-fits-all answer, industry benchmarks and regulatory guidelines provide a solid starting point. For most European SMBs, a realistic cybersecurity budget falls between 0.5% and 2% of annual revenue [3, 4]. However, this figure can rise to 2-3% for businesses in regulated sectors or those with a higher risk profile [3, 4].

A recent report from the European Union Agency for Cybersecurity (ENISA) reveals that information security now accounts for 9% of total IT investments in the EU, a significant increase from previous years [5]. This trend underscores the increasing awareness among businesses of the vital importance of cybersecurity.

The following text provides a breakdown of recommended cybersecurity spending based on an SMB’s risk profile:

Sector/Risk Level: % of Revenue (Annual)/ Typical Uses

• Non-critical SMB: 0.5 – 1.2%/ Cyber hygiene, awareness, basic technical controls [3, 4]

• Moderate/Compliance-driven: 1.2 – 2%/ Policy, advanced protection, monitoring, response, audits [3, 4]

• Critical/Regulated/NIS2 exposed: 2 – 3%/ Full baseline + incident response + external reviews [3, 4]

Note: Please be aware that these figures serve as a guide only. The actual amount an SMB needs to spend on cybersecurity will depend on several factors, including its size, industry, risk tolerance, and regulatory obligations. For micro-enterprises, a minimum annual investment of €8,500–€20,000 is often required to establish a basic level of security [3].

The NIS2 Directive: A New Era of Cybersecurity for Europe

The European cybersecurity landscape is undergoing a significant transformation with the introduction of the NIS2 Directive. This new legislation expands the scope of the original NIS Directive to include a broader range of sectors and entities, placing a greater emphasis on cybersecurity risk management and incident reporting. As a result, many SMBs that were previously not subject to these regulations will now need to step up their cybersecurity game.

A recent ENISA report found that while 92% of in-scope entities are aware of the NIS2 Directive, a significant number of organizations, particularly SMEs, are struggling to prepare for compliance [5]. The report highlights the following key challenges:

• Budgetary Constraints: A concerning 34% of SMEs report that they will not be able to secure the additional budget required for NIS2 compliance [5].

• Workforce Shortages: The cybersecurity skills gap remains a significant obstacle, with 59% of SMEs struggling to fill crucial cybersecurity roles [5]. This is particularly alarming given that 89% of organizations expect to need additional staff to comply with the new directive.

Despite these challenges, the NIS2 Directive also presents an opportunity for SMBs to strengthen their security posture and gain a competitive advantage. By embracing the principles of the directive, businesses can not only reduce their risk of cyberattacks but also build trust with customers and partners.

Conclusion: A Proactive Approach to Cybersecurity

In our current world, cybersecurity is not just an IT issue; it is a fundamental cornerstone of any business. For SMBs, the financial and reputational consequences of a cyberattack can be devastating. By taking a proactive and strategic approach to cybersecurity spending, businesses can significantly reduce their risk and build a more resilient organization.

The key takeaways for SMBs are:

• Acknowledge the Risk: Understand that no business is too small to be a target.

• Budget Accordingly: Allocate a realistic portion of your revenue to cybersecurity, using the benchmarks provided in this article as a guide.

• Prioritize Spending: Focus on the most critical areas, such as data protection, employee training, and incident response.

• Embrace Regulation: View the NIS2 Directive not as a burden, but as an opportunity to improve your security posture.

• Seek Expertise: Don’t hesitate to engage with managed service providers (MSPs) or cybersecurity consultants to supplement your in-house capabilities.

By investing in cybersecurity today, SMBs can safeguard their future and continue to thrive in an increasingly digital world.

---

References

[1] Microsoft, “7 cybersecurity trends for small and medium businesses,” Microsoft Security Blog, October 31, 2024. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2024/10/31/7-cybersecurity-trends-and-tips-for-small-and-medium-businesses-to-stay-protected/

[2] ConnectWise, “SMB cybersecurity statistics and trends in 2025,” ConnectWise Blog, July 8, 2025. [Online]. Available: https://www.connectwise.com/blog/smb-cybersecurity-statistics-and-trends

[3] Business.com, “How Much Should Your SMB Budget for Cybersecurity?” [Online]. Available: https://www.business.com/articles/smb-budget-for-cybersecurity/

[4] TotalAssure, “Cost of Cybersecurity for Small Businesses in 2025,” [Online]. Available: https://totalassure.com/blog/Cost-of-Cybersecurity-for-Small-Businesses-in-2025

[5] ENISA, “Navigating cybersecurity investments in the time of NIS 2,” November 22, 2024. [Online]. Available: https://www.enisa.europa.eu/news/navigating-cybersecurity-investments-in-the-time-of-nis-2

Better Cybersecurity: 10 Steps to Wisdom

Over the past two years, I have been speaking with startup leaders about their security. What did I learn, and can I condense the entire process into ten easy-to-follow steps? A cybersecurity manifesto of sorts.

The 10-Step Path to a Better Security Posture

1. Understand the Business and Its Mission.

   • Before you can protect anything, you have to know what's worth protecting. This step involves aligning security goals with the organization's overall mission and objectives. You need to identify the critical business functions, the information that supports them, and the impact of a disruption. Without this understanding, any security efforts are just shooting in the dark. As an ISSMP, your job is to speak the language of the business, not just the language of tech.

2. Define a Security Governance Structure.

   • Security isn't an IT problem; it's a business problem. A formal governance structure clarifies who is responsible for what, from the board of directors down to the end-user. This ensures accountability and makes security an integral part of the business, not an afterthought. This includes defining the roles of key stakeholders and recognizing the sources of authorization for security decisions.

3. Conduct a Comprehensive Risk Management Program.

   • Security is all about managing risk. This step involves identifying threats, vulnerabilities, and potential impacts. Once you have the data, you can evaluate the risks and recommend appropriate countermeasures. This isn't a one-time event; it's a continuous process of assessment and mitigation. A good risk management program also helps you justify security spending to management.

4. Develop a Robust Security Policy Framework.

   • A robust security program requires a solid foundation of well-defined policies, standards, and procedures. This framework guides employee behavior, establishes internal rules, and ensures compliance with external regulations. Policies should be practical, enforceable, and supported by all levels of the organization. Remember to include a process for periodic review to keep the framework up to date.

5. Manage Security in the System Lifecycle.

   • Security must be integrated into every phase of a system's life, from conception to disposal. This includes identifying security requirements early on, building security controls into the design, and monitoring for compliance throughout the system's life. It's much cheaper and more effective to bake security in than to bolt it on later. This also includes managing the security implications of new initiatives, such as cloud computing and big data.

6. Establish a Strong Vulnerability Management Program.

   • An organization's security is only as strong as its weakest link. This step involves continuous monitoring for threats and vulnerabilities, including regular penetration testing and vulnerability scanning. You need a process to prioritize these issues based on risk and a plan for addressing and remedying them. This proactive approach helps you identify and resolve issues before an attacker can.

7. Manage Contracts and Agreements with Security in Mind.

   • In today's interconnected world, you are responsible for the security of your partners, vendors, and service providers. This step involves evaluating security risks in contracts and agreements, including Service Level Agreements (SLAs). You must also monitor and enforce compliance with these agreements to ensure that third parties are meeting your security standards.

8. Develop and Maintain Contingency Plans.

   • Hope for the best, but plan for the worst. This step involves creating and maintaining plans for business continuity (BCP) and disaster recovery (DRP). These plans ensure that the business can continue to operate and recover from any significant disruption, from a localized outage to a regional disaster. Ensure coordination with key stakeholders and oversee the Business Impact Analysis (BIA) process.

9. Oversee a Security Awareness, Education, and Training Program.

   • People are often the weakest link in security, but they can also be your strongest defense. This program aims to promote a security-conscious culture by training employees on their roles and responsibilities. The goal is to make sure every individual understands the importance of security and how to identify and report potential incidents.

10. Measure and Report Security Metrics.

    • You can't manage what you can't measure. This final step involves defining and reporting on key performance indicators (KPIs) to measure the effectiveness of your security program. By using metrics, you can demonstrate the value of security to management, justify budget requests, and drive continuous improvement.

If you follow these steps, your organization will emerge at the other end more secure and resilient.

Is Your Incident Response Plan Ready for the Spotlight?

This article is meant to be a checklist for your IR team to ensure that the tool will function as intended when it is used.

Introduction

In the ever-evolving world of cybersecurity, having an Incident Response Plan (IRP) is like having a fire extinguisher in your kitchen. You hope you never have to use it, but when a fire breaks out, you'll be incredibly grateful it's there.

However, just like a fire extinguisher, an IRP isn't a "set it and forget it" tool. With regulatory bodies increasing scrutiny and cyber threats becoming more sophisticated, a dusty, outdated IRP is as useful as a chocolate teapot. Many organizations have existing incident response programs, but given recent regulatory developments, these plans need to be expanded to increase the depth and scope of escalation, as well as to clarify roles, responsibilities, and communication channels.

The Critical Role of Incident Triage

When a security incident occurs, the first few moments are critical. It's the difference between a small, contained spark and a raging inferno. This is where incident triage comes in.

During the incident triage process, while an initial impact assessment is being performed, a quick checkpoint should be in place to determine which stakeholders should receive early notification of the incident. Think of it as the "should I shout 'FIRE!' yet?" moment. The key is to have a pre-defined process for this, so you're not making it up on the fly while the digital flames are licking at your servers.

When to Sound the Alarm: Escalation Criteria

Your organization must have clearly defined, documented escalation criteria that specify when an incident should be escalated after the triage stage is completed.

Of course, these criteria will vary from organization to organization. They will be based on several factors, like the incident's severity, relevant regulatory and compliance requirements, materiality, potential impact, and specific policies. For example, a data breach involving a certain number of customer records or a security incident with a particular risk rating might trigger an automatic escalation. Without these clear triggers, you risk either crying wolf for every minor issue or, worse, fiddling while your digital Rome burns.

Who Needs to Know?

Not every incident requires a full-blown, all-hands-on-deck response.

Your board of directors probably doesn't need to be woken up at 3 AM because a single employee clicked on a phishing link. Therefore, a clearly defined hierarchy of escalation levels should be developed, with each level representing a higher degree of severity.

For example, an organization might have three levels:

• Level 1: Minor Incidents: Handled by the IT/security team with no immediate external reporting required.

• Level 2: Moderate Incidents: Requiring involvement from legal and communications teams, with potential reporting to regulators.

• Level 3: Major or Critical Incidents: Involving the executive leadership team (ELT), the board, and immediate notification to relevant authorities.

This tiered approach ensures that the right people are involved at the right time, without causing unnecessary panic or alert fatigue.

Roles and Responsibilities

Your incident response program should have clearly defined and documented roles and responsibilities for the individuals or teams involved in each incident escalation level.

This includes specifying who is responsible for coordinating the response, communicating with stakeholders, conducting investigations, and making decisions. Without this clarity, you'll have a chaotic situation where everyone is pointing fingers, and no one is taking charge. It's like a scene from a disaster movie, but with more spreadsheets and less dramatic music.

Incident Communication

Your IRP should also clearly define and document plans for internal and external communications, including communication channels, methods, and responsible parties for each escalation level.

The plan should include information on whom to notify and how to notify them, as well as any templates or scripts for incident reporting. This is not the time to be winging it. Having pre-approved communication templates can save you valuable time and prevent you from saying the wrong thing in the heat of the moment.

Reporting and Response Timeframes

In the world of incident response, the clock is always ticking. Regulatory bodies are imposing increasingly strict deadlines for reporting cybersecurity incidents.

For example, the EU's General Data Protection Regulation (GDPR) requires notification within 72 hours of becoming aware of a data breach [1]. In the US, the Health Insurance Portability and Accountability Act (HIPAA) requires notification without unreasonable delay and in no case later than 60 days following the discovery of a breach of unsecured protected health information [2].

Reporting Incidents: A a quick look at some of the reporting timeframes.

This table is for illustrative purposes and is not an exhaustive list. Always consult with legal counsel to ensure compliance with all applicable regulations.

Real-World Incident Response Failures

The headlines are filled with stories of companies that have suffered massive data breaches. While the technical details of these attacks are often complex, the incident response (or lack thereof) is often a key factor in the severity of the outcome. Let's look at a few examples:

The Change Healthcare Catastrophe

In February 2024, Change Healthcare, a subsidiary of UnitedHealth Group, was hit by a ransomware attack that crippled the US healthcare system [3]. The attackers, the BlackCat group, exfiltrated sensitive data and deployed ransomware, halting electronic payments and medical claims processing. The financial fallout was staggering, with UnitedHealth estimating the response cost at approximately $2.87 billion. To make matters worse, the company confirmed it paid a $22 million ransom. This incident exposed the massive vulnerabilities in the healthcare sector's cybersecurity and the devastating consequences of a poorly executed incident response.

The Snowflake Fiasco

In May 2024, the cloud data platform Snowflake experienced a significant data breach that affected over 100 of its customers, including major corporations like AT&T and Ticketmaster [3]. The attackers, associated with the Scattered Spider group, exploited the compromised credentials of a Snowflake employee account. The breach highlighted critical security lapses, particularly the absence of multi-factor authentication (MFA) and inadequate credential management among Snowflake's clientele. The attackers demanded ransoms ranging from $300,000 to $5 million from affected companies, underscoring the importance of a robust and well-rehearsed incident response plan.

The UK Ministry of Defence's Supply Chain Nightmare

Also in May 2024, the UK's Ministry of Defence (MoD) experienced a significant data breach when a contractor-operated payroll system was compromised [3]. The personal information of approximately 270,000 current and former UK military personnel was exposed. This incident highlighted the critical importance of robust cybersecurity measures, particularly in relation to third-party service providers. It's a stark reminder that your security is only as strong as your weakest link, and your IRP needs to account for your entire supply chain.

Don't Wait for the Smoke to Clear

Don't think that an effective Incident Response Plan is a luxury. Nor is it something your small organization cannot attain. With the right guidance and some effort, your team can also develop a robust plan that may make the difference between life and death for your organization when the time comes.

The cost of a data breach is not just financial; it also affects reputation. As the regulatory landscape becomes more stringent and cyber threats become more sophisticated, organizations can no longer afford to treat their IRP as a checkbox exercise. It's time to dust off that plan, put it to the test, and make sure it's ready for the spotlight. Because when a crisis hits, you don't want to be left holding a chocolate teapot.

Over and out.

---

References

[1] General Data Protection Regulation (GDPR) - https://gdpr-info.eu/art-33-gdpr/

12] Health Insurance Portability and Accountability Act (HIPAA) - https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html

[3] Cyber Management Alliance - Top 10 Biggest Cyber Attacks of 2024 - https://www.cm-alliance.com/cybersecurity-blog/top-10-biggest-cyber-attacks-of-2024-25-0ther-attacks-to-

know-about

A Startup Guide to Risk Appetite and Risk Tolerance

For the C-Suite of high-growth technology startups, the path to success is paved with risk. Every decision, from launching a new product to entering a new market, carries a degree of uncertainty. The ability to effectively navigate this complex risk landscape is what separates thriving startups from those that falter. This white paper provides a comprehensive guide for tech startup executives on defining and implementing risk appetite and risk tolerance. It offers practical, actionable frameworks and real-world examples to help you not only manage risk but also leverage it as a strategic enabler for sustainable growth.

Introduction

In the fast-paced world of tech startups, there is a constant pressure to innovate, grow, and disrupt. This often requires taking significant risks. However, without a clear understanding of how much risk your organization is willing and able to take, you are essentially flying blind. This is where the concepts of risk appetite and risk tolerance become critical.

This white paper will demystify these often-misunderstood terms and provide a clear roadmap for their implementation. We will explore:

• The fundamental differences between risk appetite and risk tolerance.

• A practical, step-by-step framework for defining and implementing risk appetite and tolerance in your startup, aligned with the globally recognized ISO 31000 standard.

• How to use risk appetite and tolerance to guide your business strategy and drive competitive advantage.

• The critical role of risk appetite and tolerance in shaping your cybersecurity strategy and protecting your most valuable assets.

By the end of this document, you will have acquired the knowledge and tools to build a robust risk management framework that not only protects your organization but also empowers you to make bolder, more informed decisions in pursuit of your strategic objectives.

Defining the Core Concepts

To effectively manage risk, it is crucial to have a clear understanding of two core concepts: risk appetite and risk tolerance. While often used interchangeably, they represent distinct but interconnected elements of a robust risk management framework.

Risk Appetite

Risk appetite refers to the amount and type of risk that an organization is willing to undertake or retain to achieve its strategic objectives [1]. It is a high-level statement that reflects the organization’s risk culture and philosophy. As the Institute of Risk Management (IRM) puts it, risk appetite is about the “pursuit of risk” [2].

For a tech startup, a well-defined risk appetite provides a strategic compass, guiding decisions on everything from product development to market expansion. It helps answer the fundamental question: “How much risk are we willing to take to achieve our ambitious goals?”

According to the ISO 31000 framework, risk appetite can be broadly categorized into three types [3]:

Risk Appetite Categories, according to ISO/IEC 31000

Risk Tolerance

Risk tolerance, on the other hand, is more granular and tactical. It is the acceptable level of deviation from the organization’s risk appetite [4]. While risk appetite is a strategic statement of intent, risk tolerance defines the specific, measurable boundaries of acceptable risk-taking. It is about what an organization can actually cope with [2].

For a tech startup, risk tolerance translates the high-level risk appetite into actionable guidance for day-to-day operations. It answers the question: “What are the specific limits we will not exceed in the pursuit of our objectives?”

“The risk appetite statement is generally considered the hardest part of any enterprise risk management implementation. However, without clearly defined, measurable tolerances, the whole risk cycle and any risk framework is arguably at a halt.”

— Jill Douglas, Head of Risk, Charterhouse Risk Management [2]

An Interconnected Relationship

Risk appetite and risk tolerance are two sides of the same coin. Risk appetite sets the strategic direction, while risk tolerance provides the operational guardrails. You cannot have one without the other. A clear risk appetite statement is meaningless without defined risk tolerances to make it actionable. Conversely, risk tolerances without a guiding risk appetite lack strategic context.

By defining both risk appetite and risk tolerance, tech startups can create a robust framework for making informed, risk-based decisions that align with their strategic objectives and drive sustainable growth.

Defining and Implementing Risk Appetite and Tolerance

This section provides a practical, step-by-step framework for tech startup C-suite executives to define, implement, and govern risk appetite and risk tolerance within their organizations. This framework is aligned with the principles of ISO 31000 and tailored to the dynamic nature of startups.

The 5-Step Risk Appetite and Tolerance Framework

We propose a five-step, iterative framework to embed risk appetite and tolerance into your organization’s culture and decision-making processes:

1. Establish Context: Understand the internal and external factors that shape your startup’s risk landscape.

2. Define Risk Appetite: Articulate your high-level willingness to take on risk to achieve your strategic objectives.

3. Define Risk Tolerance: Translate your risk appetite into specific, measurable, and actionable thresholds.

4. Operationalize and Communicate: Integrate risk appetite and tolerance into daily operations and decision-making.

5. Monitor and Review: Continuously assess the effectiveness of your framework and adapt to changing conditions.

Step 1: Establish Context

Before we can define your risk appetite, we must understand your startup’s unique context. This involves analyzing both internal and external factors. Below, some questions might help define both:

Internal factors:

• What are our mission, vision, and strategic objectives?

• What is our current financial position and funding runway?

• What is our team’s expertise and capacity for risk management?

• What is our organizational culture regarding risk and innovation? 

External factors:

• Who are our key stakeholders (investors, customers, partners, regulators)?

• What is the competitive landscape?

• What are the prevailing economic and market conditions?

• What are the relevant legal, regulatory, and contractual requirements?

Step 2: Define Risk Appetite

Now that we have a clear understanding of the context, we can define the organization’s risk appetite. Remember: this is a high-level, qualitative statement that sets the tone for your risk culture.

Example Risk Appetite Statements for a Tech Startup:

• Innovation & Product Development: “We have a high appetite for taking calculated risks in product innovation to disrupt the market and achieve rapid growth. We encourage experimentation and accept that some initiatives may fail.”

• Financial Risk: “We have a low appetite for financial risks that could jeopardize our funding runway. We will maintain a lean operational model and prioritize long-term financial stability.”

• Cybersecurity Risk: “We have a zero appetite for the loss of customer data. We will invest in robust security measures to protect our customers’ information and maintain their trust.”

• Compliance Risk: “We have a low appetite for compliance risk. We will adhere to all applicable laws and regulations in the jurisdictions where we operate.”

Step 3: Define Risk Tolerance

As a reminder, risk tolerance translates your high-level risk appetite into specific, measurable, and actionable thresholds. This is where you define the boundaries of acceptable risk-taking.

Risk Assessment Matrix

First, you need a consistent way to assess the impact and likelihood of risks. A 5x5 risk assessment matrix is a simple yet effective tool for this purpose:

Example of a Risk Assessment Heat Map

TIP: If your team has more time, I suggest checking the FAIR methodology that adds a quantification dimension to your risk assessment.

Risk Tolerance Table

Next, you can create a risk tolerance table that maps different risk categories to specific tolerance levels, like in the example below:

Step 4: Operationalize and Communicate

A risk appetite and tolerance framework is only effective if it is integrated into your startup’s daily operations and decision-making processes. Here is what to do to ensure that these become second nature for your organization:

• Integrate into workflows: Embed risk tolerance thresholds into your product development lifecycle, your budgeting process, and your incident response plans.

• Communicate clearly: Ensure that every employee understands the company’s risk appetite and their role in managing risk.

• Provide training: Conduct regular training sessions to reinforce the importance of risk management and how to use the framework.

Step 5: Monitor and Review

Note that risk management is not a one-time exercise. The risk landscape is constantly changing, and your risk appetite and tolerance framework must adapt accordingly. These are the main activities that the management team must carry out regularly (e.g., quarterly):

• Monitor KRIs: Continuously monitor your Key Risk Indicators to ensure that you are operating within your defined risk tolerance levels.

• Regular reviews: Conduct regular reviews of your risk appetite and tolerance framework (at least annually) to ensure that it remains aligned with your strategic objectives and the external environment.

• Post-incident reviews: After any significant risk event, conduct a post-incident review to identify lessons learned and update your framework as needed.

Guiding Business Strategy with Risk Appetite and Tolerance

A well-defined risk appetite and tolerance framework is not just a defensive tool for managing threats; it is a powerful enabler of strategic growth. By providing a clear understanding of the risks your organization is willing to take, it empowers you to make bolder, more informed decisions in the pursuit of your strategic objectives. This section highlights some benefits that demonstrate the value of this exercise for your organization.

Aligning Risk and Strategy

For a tech startup, the alignment of risk and strategy is critical. Your risk appetite should be a direct reflection of your strategic goals.

If your strategy is to disrupt a market with a groundbreaking new product, your risk appetite in product innovation should be high. Conversely, to build a reputation for reliability and trust, your risk appetite for operational and compliance risks should be low.

For example, a tech startup focusing on artificial intelligence may exhibit a high risk appetite, investing aggressively in research and market entry despite uncertainties about regulatory approvals or market acceptance. In contrast, a utility company might adopt a lower risk appetite, prioritizing regulatory compliance and stable operations to maintain trust and reliability. [5]

By explicitly defining your risk appetite, you can ensure that your strategic decisions are consistent with your risk-taking philosophy. This prevents the kind of strategic drift that can occur when decisions are made on an ad-hoc basis, without a clear understanding of the associated risks.

Enabling Proactive and Agile Decision-Making

In the fast-paced world of tech startups, the ability to make quick, decisive decisions is a key competitive advantage. A well-defined risk appetite and tolerance framework provides the guardrails that enable you to move quickly without being reckless.

When a new opportunity arises, you can evaluate it against your predefined risk appetite. If it falls within your acceptable risk parameters, you can move forward with confidence. If it falls outside your risk appetite, you can either reject the opportunity or develop a plan to mitigate the risks to an acceptable level.

This proactive approach to risk management allows you to seize opportunities that your more risk-averse competitors might shy away from, while still protecting your organization from catastrophic losses.

Optimizing Resource Allocation

Every startup has limited resources. A clear risk appetite and tolerance framework helps you allocate those resources more effectively. By understanding which risks you are willing to take and which you are not, you can prioritize your investments in risk mitigation.

For example, if you have a low appetite for cybersecurity risk, you will allocate a larger portion of your budget to security measures. If you have a high appetite for product innovation risk, you will allocate more resources to research and development.

This risk-based approach to resource allocation ensures that you are focusing your efforts on the areas that are most critical to your success.

Shaping Cybersecurity Strategy with Risk Appetite and Tolerance

In today’s hyper-connected world, cybersecurity is not just an IT issue; it is a critical business risk. For tech startups, a single cybersecurity breach can be catastrophic, leading to financial loss, reputational damage, and even business failure. A well-defined risk appetite and tolerance framework is therefore an essential tool for shaping your cybersecurity strategy and protecting your most valuable assets.

From Abstract Policy to Actionable Guardrails

Too often, cybersecurity policies are written once and then filed away, having little impact on the organization’s actual security posture. A risk appetite and tolerance framework, on the other hand, provides a set of actionable guardrails that can guide your day-to-day security decisions.

As the FAIR Institute notes, “Clear, measurable cyber risk tolerance statements turn abstract policy into practical decision-making tools” [6]. By defining your tolerance for specific cybersecurity risks, you can empower your security team to prioritize threats, respond to incidents with confidence, and make informed decisions about where to invest your limited security resources.

Sample Cybersecurity Risk Appetite and Tolerance Statements

Here are some examples of how a tech startup might define its risk appetite and tolerance for cybersecurity:

Risk Appetite Statement:

“We have a zero appetite for breaches of regulated customer data. We will invest in best-in-class security measures to protect our customers’ information and maintain their trust.”

Risk Tolerance Statements:

• “We tolerate up to 5 critical vulnerabilities per month in production systems, with remediation completed within 10 business days.” [6]

• “We tolerate a phishing click rate of up to 2% across the workforce per quarter.” [6]

• “We tolerate zero unauthorized access events to production systems. Any event triggers immediate incident response and executive notification.” [6]

These specific, measurable, and time-bound tolerance statements provide clear guidance to the security team and enable the C-suite to monitor the organization’s security posture effectively.

Three Strategic Roles for Risk Appetite in Cybersecurity

GuidePoint Security highlights three strategic roles for risk appetite in cybersecurity [7]:

1. Prioritization Framework: Your risk appetite helps you prioritize which risks to address first. For example, if you have a low appetite for ransomware risk, you will prioritize investments in endpoint detection and response (EDR), data backups, and phishing training.

2. Alignment Tool Across Departments: A clear risk appetite provides a common language for discussing risk across the organization. This helps to align the CISO, CTO, and other business leaders on security priorities.

3. Investment Justification: Your risk appetite statement can be a powerful tool for justifying security investments. By linking your budget requests to board-approved risk thresholds, you can demonstrate that you are not just spending money on security, but making strategic investments to protect the business.

By integrating risk appetite and tolerance into your cybersecurity strategy, you can move from a reactive, compliance-driven approach to a proactive, risk-based approach that is aligned with your business objectives and focused on protecting what matters most.

From Risk Management to Risk Leadership

For tech startups, risk is not something to be avoided; it is a fundamental part of the journey. The ability to take calculated risks is what drives innovation, fuels growth, and creates lasting value. However, without a clear and deliberate approach to risk management, startups can easily fall prey to the very risks they need to take to succeed.

A well-defined risk appetite and tolerance framework, aligned with the principles of ISO 31000, provides the essential guardrails for navigating the complex risk landscape of the startup world. It enables you to move from a reactive, ad-hoc approach to risk management to a proactive, strategic approach that is aligned with your business objectives.

By defining your risk appetite, you set the strategic direction for your organization’s risk-taking. By defining your risk tolerance, you translate that strategy into actionable guidance for your team. And by integrating this framework into your business and cybersecurity strategies, you empower your organization to make bolder, more informed decisions with confidence.

Ultimately, the goal is to move beyond mere risk management to risk leadership. This means not only protecting your organization from threats but also leveraging risk as a strategic enabler of growth and innovation. By embracing a culture of risk-aware decision-making, you can build a more resilient, agile, and successful startup that is prepared to thrive in the face of uncertainty.

---

References

[1] ISACA. (2022, October 24). Risk Appetite vs. Risk Tolerance: What is the Difference? ISACA Now Blog. Retrieved from https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2022/risk-appetite-vs-risk-tolerance-what-is-the-difference

[2] The Institute of Risk Management. (n.d.). Risk appetite and tolerance. Retrieved from https://www.theirm.org/what-we-say/thought-leadership/risk-appetite-and-tolerance/

[3] Learn31000. (n.d.). Risk Appetite. Retrieved from https://learn31000.com/risk-appetite/

[4] ISACA. (n.d.). Risk IT Framework, 2nd Edition. (As cited in ISACA Now Blog, “Risk Appetite vs. Risk Tolerance: What is the Difference?”)

[5] SearchInform. (n.d.). Risk Appetite: The Foundation of Strategic Risk Management. Retrieved from https://searchinform.com/articles/risk-management/governance/risk-appetite/

[6] FAIR Institute. (2025, August 25). Creating Cyber Risk Tolerance Statements: Turn Strategy into Guardrails. Retrieved from https://www.fairinstitute.org/blog/creating-cyber-risk-tolerance-statements

[7] GuidePoint Security. (2025, July 23). The Strategic Power of Cyber Risk Appetite: Making Security Decisions with Clarity and Confidence. Retrieved from https://www.guidepointsecurity.com/blog/the-strategic-power-of-cyber-risk-appetite-making-security-decisions-with-clarity-and-confidence/

Ditch that Password! Why Your Business Needs to Embrace Passkeys

Introduction

Passwords are the weakest link in your business's security chain. They're a hassle to remember, a nightmare to manage, and a prime target for cybercriminals. But what if there was a better way? A way to secure your business that's not only stronger but also simpler and more user-friendly? Enter passkeys, the next-generation authentication technology that's poised to make passwords a thing of the past.

In this article, we'll explore why your business needs to move away from passwords and embrace passkeys. We'll cover what passkeys are, how they work, and the significant security and usability benefits they offer. We'll also provide practical, step-by-step guides to help you enable passkeys in two of the most common small business platforms: Google Workspace and Microsoft 365. It's time to say goodbye to password-related headaches and hello to a more secure and streamlined future for your business.

What Are Passkeys and How Do They Work?

At its core, a passkey is a digital credential that replaces your traditional password. It's a more secure and convenient way to log in to your accounts, using your phone, computer, or other supported device to verify your identity. Instead of typing in a password, you use your device's built-in authentication method, such as a fingerprint, facial scan, or PIN.

So, how does this magic work? Passkeys are based on a technology called public-key cryptography. When you create a passkey for a website or application, your device generates a unique pair of cryptographic keys: a public key and a private key.

• The public key is stored on the website or application server. It's not a secret and can be seen by anyone.

• The private key is stored securely on your device and never leaves it. This is the key that proves your identity.

When you want to log in, the website sends a challenge to your device. Your device uses the private key to "sign" the challenge and send it back. The website then uses your public key to verify the signature. If it matches, you're in! The beauty of this system is that your private key, the key that actually verifies your identity, never has to be transmitted over the internet. This makes it incredibly resistant to phishing attacks and data breaches.

This entire process is governed by the FIDO (Fast Identity Online) Alliance, a consortium of tech giants like Google, Apple, and Microsoft, who are all working together to create a passwordless future. This collaboration ensures that passkeys are a standardized and interoperable technology that will work seamlessly across different devices and platforms.

Security and Usability Benefits

The move to passkeys isn't just about getting rid of annoying passwords; it's about fundamentally upgrading your business's security posture while simultaneously improving the user experience for your employees. Here are some of the key benefits:

• Passkeys are inherently resistant to phishing attacks. Because the private key never leaves the user's device, there's no secret for a phisher to steal. Even if an employee is tricked into visiting a fake website, the passkey won't work because it's tied to the legitimate website's domain.

• Passkeys are based on strong cryptographic principles, making them significantly more secure than even the most complex passwords. They eliminate the risks associated with password reuse, weak passwords, and credential stuffing attacks.

• No more forgotten passwords, no more frustrating password reset processes. With passkeys, your employees can log in to their accounts with a simple touch or glance. This not only improves productivity but also reduces the burden on your IT support team.

• Thanks to the efforts of the FIDO Alliance, passkeys can be synced across devices. This means an employee can create a passkey on their work computer and then use it to log in on their phone, creating a seamless and consistent user experience.

• By eliminating passwords, you can significantly reduce the number of password-related support tickets your IT team has to handle. This frees up their time to focus on more strategic initiatives.

How to Enable Passkeys

Most common applications used by small (and big) organizations already support passkeys. Below you will find a step-by-step guide to get your organization started right away.

Google Workspace

For businesses that run on Google Workspace, enabling passkeys is a straightforward process that can be done from the Google Admin console. Here’s how to do it:

1. Sign in to the Google Admin console. You’ll need to be a super administrator or have the appropriate security administrator privileges.

2. Navigate to Security > Authentication > Passwordless. This is where you’ll find the settings for enabling passkeys.

3. Enable the Skip passwords setting.

4. Check the box to “Allow users to skip their password and authenticate with a passkey.”

5. Optional) Apply to specific organizational units — If you want to roll out passkeys to a particular department or team first, select the corresponding organizational unit.

6. Save your changes. Once you’ve enabled the setting, your users will be able to create and use passkeys to log in to their Google Workspace accounts.

It’s important to note that once you enable this setting, your users will be prompted to create a passkey the next time they log in. You should communicate this change to your employees and provide them with instructions on how to generate a passkey. Google offers a straightforward, user-friendly process for this, allowing users to typically create a passkey in just a few clicks.

Microsoft 365

For businesses that use Microsoft 365, passkeys are managed through Microsoft Entra ID (formerly Azure Active Directory). Here’s how to enable them:

1. Sign in to the Microsoft Entra admin center. You’ll need to be an Authentication Policy Administrator.

2. Navigate to Entra ID > Authentication methods > Policies. This is where you’ll find the settings for various authentication methods.

3. Enable the “Passkey (FIDO2)” method. Set the toggle to “Enable” and choose whether to apply it to all users or specific groups.

4. Configure the settings. You’ll have the option to allow self-service setup, enforce attestation (to ensure that only genuine FIDO2 devices are used), and enforce key restrictions (to allow only specific types of security keys).

5. Save your changes. Once you’ve saved your changes, your users will be able to register and use passkeys to log in to their Microsoft 365 accounts.

Similar to Google Workspace, it’s important to communicate this change to your employees and provide them with instructions on how to register a passkey. Microsoft provides a user-friendly process for this, and users can typically register a passkey in just a few steps.

The Future is Passwordless

The transition to a passwordless future is not a matter of if, but when. Passkeys represent a significant leap forward in authentication technology, offering a solution that is both more secure and more user-friendly than traditional passwords. By embracing passkeys now, you can not only improve your business’s security posture but also create a more seamless and productive experience for your employees.

The time to ditch the password is now. Start your journey to a passwordless future today.

---

References

• Google for Developers: Passkeys

• WIRED: What Is a Passkey? Here’s How to Set Up and Use Them (2025)

• Google Workspace Admin Help: Allow users to skip passwords at sign-in

• Microsoft Learn: Enable passkeys for your organization

• Passkeys.io: Websites and Apps with Passkey Support

How the Language used in your Security Policies could land you in Legal Hot Water

How a single word in your security policy could cost you thousands in legal fees

Introduction

We've all been there: you crafted what seems like a bulletproof security policy. Your legal team approved it, executives signed off, and employees were trained. Then one day, an employee violates your security protocols, and suddenly you're in court explaining why you fired Sarah from accounting but only gave Mike from marketing a written warning for what appears to be the same violation.

Welcome to the world where words have consequences—sometimes costly ones.

As one security expert put it, "A roar from a paper tiger does little to prompt action; appropriate disciplinary action is an essential part of enforcement." But here's the twist many organizations miss: the language you use to describe that disciplinary action can either be your legal shield or your legal sword—pointed directly at your own throat.

The Million-Dollar Word: "Will" vs "May"

Consider for a moment these two policy statements:

"The enterprise will terminate employees who violate our data protection protocols"

"The enterprise may terminate employees who violate our data protection protocols."

That single word change ('will’ vs 'may') represents the difference between a mandatory obligation that locks your organization into forced action and a discretionary framework that provides flexibility to consider circumstances, intent, and proportionality.

Mandatory Language Becomes Legal Liability

According to lawyers, when you use "will" in security policies, you're creating what legal experts call a "mandatory obligation." Every time an employee violates the specified policy, your organization must (i.e., is legally bound) take the promised action—regardless of circumstances, intent, or actual impact. That is, once you've committed to that language, you've removed any discretion you might choose to apply. If you said you "will" terminate employees for certain violations, then you must terminate all employees for those violations, creating several dangerous scenarios, like in these examples:

• Terminate Sarah for accidentally emailing client data to the wrong address, but only warn Mike for downloading unauthorized software? Sarah's attorney may argue that there is gender discrimination, using your policy language as evidence.

• A new employee accidentally clicking a phishing link presents a very different situation than a veteran deliberately circumventing security controls. Mandatory termination language eliminates your ability to consider these crucial differences.

Perhaps more importantly here, if employees see colleagues terminated for minor mistakes while serious violations by others are handled differently, it creates fear and inconsistency that undermines the effectiveness of your security posture.

The "May" Safety Net

In the previous example, using 'may' language transforms your policy from a rigid mandate into a flexible framework. According to Cornell Law School, 'may’ is "an expression of possibility, a permissive choice to act or not, and ordinarily implies some degree of discretion."

And this discretion provides critical advantages:

• Proportional responses: Match punishment to the severity and intent of the violation

• Protection against discrimination claims: Different consequences can be justified based on circumstances

• Managerial flexibility: Supervisors can make thoughtful decisions without being locked into predetermined outcomes

• Reduced legal exposure: Avoid wrongful termination lawsuits based on inconsistent policy enforcement

Other Common Language Traps

The "Shall" Confusion

"Shall" may sound official and legal, but it's often misused. The Michigan State Bar found that 56% of "shall" usage in contracts was legally problematic. Legal experts recommend avoiding the use of "shall" entirely in policy language, as it creates confusion about whether provisions are mandatory or descriptive.

Instead of:

"Employees shall report security incidents within 24 hours.” Consider: "Employees must report security incidents within 24 hours."

Absolute Statements Create Absolute Liability

Let's consider other examples: "zero tolerance," "all violations," and "never acceptable"—these absolute terms sound strong but can create legal nightmares when reality proves more complex than your policy anticipated. Why?

• The Problem: "All security violations will result in immediate termination." Better: "Security violations may result in disciplinary action up to and including termination."

Additionally, phrases such as "appropriate action," "serious violations," or "reasonable security measures" offer no clear guidance and result in inconsistent enforcement. So, instead of: "Violations will result in appropriate disciplinary action”, consider instead: "Violations may result in verbal warning, written warning, suspension, or termination."

Real-World Consequences

A financial services company learned this lesson the hard way. Their policy stated: "Any employee who transmits confidential client information to unauthorized recipients will be immediately terminated."

When two similar incidents occurred—one involving a 45-year-old senior manager's accidental email error, and another involving a 28-year-old analyst deliberately forwarding client data to a personal email—management terminated the younger employee but issued a warning to the senior manager.

The result? A discrimination lawsuit costing $180,000 in legal fees plus a $95,000 settlement. The company's own "will be terminated" language became the centerpiece of the case against them.

Your Action Plan: Fix Your Policies Today

Review your security policies and look for examples of the above. Understanding policy language isn't just about protecting your organization—it's about advancing your career. Cybersecurity professionals who can bridge the gap between technical requirements and legal compliance are incredibly valuable.

Your security policies should protect your organization, not prosecute it. The difference between protection and prosecution often comes down to a single word choice.

Every word in your security policies carries weight. "Will" versus "may" isn't just semantics—it's the difference between flexibility and rigidity, between policies that serve your organization and policies that could destroy it.

The organizations that thrive will be those that recognize policy language as a strategic asset rather than a compliance burden. They'll invest in getting the language right, train managers to implement policies effectively, and create cultures where security and legal compliance work together.

Key Takeaways

• Replace "will" with "may" in disciplinary language to preserve flexibility

• Avoid absolute terms like "zero tolerance" that eliminate discretion

• Use the present tense instead of confusing "shall" language

• Define vague terms like "serious violations" with specific examples

• Include flexibility clauses that allow consideration of circumstances

• Conduct regular policy audits to identify problematic language

• Train managers on proper policy implementation and documentation

• Consider policy language a strategic business decision, not just legal compliance

You can find out more about how to use plain language in contracts in this podcast.

Cybersecurity Career Progression: From Analyst to Leader

Strategic insights for advancing your cybersecurity career, based on lessons learned from nearly two decades in the field.

Beyond the Entry Level

You've landed your first cybersecurity job, proven you can handle the basics, and now you're wondering what comes next. After spending the better part of two decades in this field and watching countless professionals navigate their career progression, I can tell you that advancement in cybersecurity requires more than just accumulating technical certifications.

The professionals who advance most successfully understand that cybersecurity careers aren't linear. Unlike traditional IT paths where you might progress from help desk to system administrator to IT manager, cybersecurity offers multiple specialization tracks, each with its advancement opportunities and requirements.

More importantly, the skills that got you your first job aren't necessarily the ones that will drive your career forward. Technical competence remains essential, but leadership, strategic thinking, and business acumen become increasingly critical as you advance.

The Specialization Decision

One of the most important career decisions you'll make is choosing your area of specialization. While it's possible to remain a generalist, most senior cybersecurity professionals have deep expertise in one or two specific areas.

Technical Specializations

These offer the clearest advancement paths for people who want to remain hands-on with technology. Penetration testing and ethical hacking can lead to senior consultant roles or specialized team leadership positions. Digital forensics and incident response specialists often become subject matter experts who command premium salaries and work on high-profile cases. Security architecture and engineering roles evolve into chief technology officer or chief information security officer positions.

The key to advancing in technical specializations is staying current with emerging threats and technologies while developing the ability to mentor junior team members. Senior technical professionals spend a significant amount of time reviewing others' work, designing security solutions, and communicating technical concepts to business stakeholders.

Management and Leadership Tracks

They focus on building and leading security teams, developing organizational security strategies, and managing security programs. These roles require strong project management skills, budget management experience, and the ability to influence without direct authority.

I've observed that the most successful security managers are those who maintain enough technical credibility to earn their team's respect while developing the business skills necessary to secure executive support for security initiatives. This balance is challenging but essential for career advancement.

Risk and Compliance

These specializations have become increasingly important as organizations face growing regulatory requirements and board-level scrutiny of cybersecurity risks. These roles involve translating technical security concepts into business risk language, managing compliance programs, and working closely with legal and audit teams.

Career advancement in risk and compliance often leads to chief risk officer positions or senior consulting roles. The work requires strong analytical skills, attention to detail, and the ability to communicate complex regulatory requirements to diverse stakeholders.

Consulting and Advisory

Becoming a consultant offers high earning potential and exposure to diverse organizations and challenges. However, they also require strong business development skills, the ability to work independently, and comfort with irregular income streams.

Successful cybersecurity consultants typically have deep expertise in specific areas combined with broad knowledge across multiple domains. They must be able to quickly assess organizational security postures, develop actionable recommendations, and communicate findings to executive audiences.

Building Leadership Skills

Technical expertise alone won't advance your cybersecurity career beyond senior individual contributor roles. Leadership skills become essential for most advancement opportunities, even if you're not managing people directly.

Project leadership experience is crucial because cybersecurity work increasingly involves cross-functional initiatives that require coordination across multiple teams and departments. Volunteer to lead security awareness campaigns, compliance audits, or technology implementations. These experiences demonstrate your ability to manage complex initiatives and work with diverse stakeholders.

Mentoring and knowledge transfer skills become essential as you advance because senior professionals are expected to develop junior team members. Start by documenting processes, creating training materials, or presenting at team meetings. These activities demonstrate your ability to share knowledge effectively and develop others.

Strategic thinking capabilities distinguish senior professionals from those who remain focused on tactical execution. This means understanding how security decisions impact business operations, anticipating future threats and challenges, and developing long-term security strategies rather than just responding to immediate problems.

Communication and influence skills are essential because senior cybersecurity professionals must regularly interact with executives, board members, and external stakeholders who don't have technical backgrounds. Practice translating technical concepts into business language, presenting to senior audiences, and building consensus around security initiatives.

The Business Acumen Imperative

One of the most significant career limitations I've observed is that cybersecurity professionals often remain focused exclusively on technical aspects without developing a business understanding. Organizations need security leaders who can balance security requirements with business objectives, rather than just relying on technical experts who say "no" to everything.

Understanding your organization's business model, revenue streams, competitive pressures, and strategic objectives enables you to make security recommendations that support, rather than hinder, business success. This business alignment is essential for securing executive support and advancing to senior leadership positions.

Financial literacy becomes increasingly important as you advance because senior cybersecurity roles involve budget management, cost-benefit analysis, and return on investment calculations. You don't need an MBA, but you should understand basic financial concepts and be able to articulate the business value of security investments.

Industry knowledge also matters because different sectors face distinct security challenges and regulatory requirements. Healthcare organizations deal with HIPAA compliance and medical device security. Financial services companies face different regulatory frameworks and threat profiles than manufacturing companies. Developing deep understanding of your industry's specific security challenges can accelerate your career advancement.

Advanced Certifications and Continuous Learning

While certifications become less important as you advance, certain credentials can accelerate career progression or open specific opportunities.

• CISSP (Certified Information Systems Security Professional) remains the most widely recognized advanced certification and is often required for senior security positions. However, it requires five years of relevant experience, making it less suitable for early-career professionals.

• CISM (Certified Information Security Manager) focuses on management and governance aspects of cybersecurity and is valuable for professionals pursuing leadership tracks.

• CISSP concentrations, such as CISSP-ISSAP (Information Systems Security Architecture Professional) or CISSP-ISSEP (Information Systems Security Engineering Professional), demonstrate specialized expertise in specific technical areas.

Industry-specific certifications can be valuable depending on your career focus. For example, cloud-focused roles benefit from advanced security certifications in AWS, Azure, or Google Cloud.

Beyond formal certifications, continuous learning through conferences, training courses, and professional development programs is essential. The cybersecurity field evolves rapidly, and staying current requires ongoing investment in education and skill development.

Navigating Organizational Politics

Career advancement in cybersecurity, like any field, involves navigating organizational dynamics and building strategic relationships. Security professionals often struggle with this aspect because they're trained to focus on technical problems rather than interpersonal dynamics.

Building alliances across the organization is crucial because cybersecurity initiatives require support from multiple departments. Develop relationships with key stakeholders in IT, legal, compliance, human resources, and business units. Understanding their priorities and challenges enables you to position security initiatives in a way that gains their support.

Managing up effectively means keeping your manager and senior executives informed about security risks, initiatives, and achievements without overwhelming them with technical details. Learn to communicate in terms of business impact rather than technical specifications.

Lateral relationship management is crucial because cybersecurity work is increasingly involving collaboration with peers in other departments. Building trust and credibility with colleagues makes it easier to implement security controls and respond to incidents effectively.

External networking through professional organizations, conferences, and industry groups can provide valuable career opportunities, facilitate knowledge sharing, and support professional development. Many senior cybersecurity positions are filled through professional networks rather than traditional job postings.

Compensation and Career Timing

Understanding compensation trends and career timing can help you make informed decisions about when to pursue advancement opportunities or consider changing organizations.

Internal advancement often provides the most predictable career progression but may limit salary growth compared to external opportunities. However, internal moves allow you to build on existing relationships and organizational knowledge.

External opportunities typically offer higher salary increases but require rebuilding relationships and learning new organizational cultures. The cybersecurity job market generally favors candidates with 3-5 years of experience, making this an optimal time for external moves.

Geographic considerations significantly impact both opportunities and compensation. Major metropolitan areas offer more opportunities and higher salaries, but also higher living costs. Remote work has expanded opportunities but may limit advancement potential in some organizations.

Industry transitions can accelerate career progression if you move to sectors with higher security maturity or greater investment in cybersecurity. However, industry-specific knowledge and relationships may not be fully transferable.

The Long-Term Perspective

Successful cybersecurity careers require long-term thinking and strategic planning. The field offers multiple paths to senior leadership positions, but each requires different skill development and accumulation of experience.

Chief Information Security Officer (CISO) positions typically require broad cybersecurity experience, strong business acumen, and proven leadership capabilities. Most CISOs have 15 years or more of experience and have held multiple senior security roles.

Specialized expert roles, such as principal security architect or senior security consultant, can offer high compensation and professional satisfaction, while avoiding traditional management responsibilities. These positions require deep technical expertise and a strong reputation within the cybersecurity community.

Entrepreneurial opportunities in cybersecurity continue to expand as organizations seek innovative security solutions. However, entrepreneurship requires business skills, risk tolerance, and often significant financial resources.

Board and advisory roles represent the pinnacle of cybersecurity career achievement and typically require extensive experience, a strong professional network, and a proven track record of success in security programs.

Be Strategic

The most successful cybersecurity professionals I know make deliberate, strategic career decisions rather than simply accepting whatever opportunities come their way. This requires regular self-assessment, market awareness, and long-term planning.

Evaluate your current skills, interests, and career objectives on an annual basis. Identify gaps between your current capabilities and your target roles, then develop specific plans to address those gaps through training, experience, or additional responsibilities.

Stay informed about industry trends, emerging threats, and evolving job requirements. The cybersecurity field is constantly evolving, and career success requires adapting to new challenges and opportunities.

Build and maintain professional relationships throughout your career. The cybersecurity community is relatively small, and professional networks often provide the best career opportunities and professional development resources.

Concluding

Remember that cybersecurity careers are marathons, not sprints. Focus on building sustainable skills, maintaining work-life balance, and contributing meaningfully to the organizations and communities you serve. The field requires experienced professionals who can provide steady leadership and strategic guidance, in addition to technical expertise.

Your cybersecurity career can be both personally rewarding and professionally successful, but it requires planning, continuous learning, and strategic relationship building. The investment is significant, but the opportunities for impact and advancement make it worthwhile for professionals committed to protecting our increasingly digital world.

---

I am a cybersecurity consultant with about 20 years of experience helping European organizations establish resilient security programs. I am the founder of BARE Cybersecurity and hold CISSP and CCSP certifications. Connect with me on LinkedIn for daily cybersecurity insights and career guidance.

Insider Threats might be your Biggest Overlooked Risk

What this Article is about

You've been building your startup from the ground up, survived the 'Valley of Death,’ and have built a team you trust. As a result, all your employees had access to basically all your valuable assets—customer data, trade secrets, and financial information. Since then, your organization has grown larger, but you didn't think about revising this lack of compartmentalization until one day, when you discovered the hard way that your most significant security threat wasn't some hoodie-wearing hacker in a basement halfway around the world. It was someone sitting right next to you in the office, maybe even sharing coffee with you in the break room.

Welcome to the world of insider threats—the cybersecurity equivalent of being betrayed by your own shadow.

If you think insider threats are just a "big company problem," think again. Recent data shows that small businesses and startups are not only frequent targets but often the most vulnerable victims of these attacks. In 2024, 83% of organizations reported at least one insider attack, and the numbers for smaller companies are particularly sobering [1].

Let's start with some hard truths that might prompt you to double-check who currently has access to your company's Google Drive.

The Size of the Problem

I have conducted some research, and the statistics surrounding insider threats are frankly terrifying, especially when broken down by company size. You will find the sources at the end of the article. Here's what the latest research reveals:

• 83% of organizations experienced at least one insider attack in 2024 [1]

• 48% of organizations report that insider attacks have become more frequent over the past 12 months [2]

• Organizations experiencing 11-20 insider attacks saw a staggering 5X increase from 2023 [1]

• The average annual cost of insider risk has reached 17.4million, up from 16.2 million in 2023 [3]

Are all the insider threats malicious? Of course not. But this doesn't make things better for your organization.

Small businesses receive the highest rate of targeted malicious emails (one in 323) [4]. To put that in perspective, if your company gets the typical 100 emails per day per office worker, you're looking at something potentially malicious content landing in the inbox every few days. Even if your employees do not intend to harm the organization, they can still be a real threat. Here are some more stats:

• 61% of small and medium businesses (SMBs) were targeted by cyberattacks in 2021 [4]

• 82% of ransomware attacks in 2021 were against companies with fewer than 1,000 employees [4]

• 37% of ransomware victims had fewer than 100 employees [4]

Because cybercriminals are aware that small businesses are often less protected, employees at small businesses are 350% more likely to experience social engineering attacks than those at larger enterprises [4].

Financial Impact

For small businesses, the financial impact of insider threats can be devastating, as the same research shows that 95% of cybersecurity incidents at SMBs cost, on average, north of $300K per incident, whilst nearly 40% of small businesses lost crucial data as a result of an attack [4]

What about cyberinsurance? Here's the kicker: only 17% of small businesses have cyber insurance [4]. That means when an insider threat materializes into a real attack, most small businesses are flying without a financial safety net.

The costs extend beyond the immediate financial impact: 55% of customers worldwide would be less likely to continue doing business with companies that have been breached [US data, 4].

Furthermore, the average cost to contain an insider incident is 211,021, while they spend 37,756* on monitoring [3]

To sum it up, it would be like spending thousands on emergency room visits while skipping your annual checkups—reactive instead of proactive, and far more expensive in the long run.

(*) As a side note, if you want to know how much to spend on security controls for a quantified risk, you may want to read my other article, "The Million-Dollar Question: Are You Spending Too Much on Risk Prevention?"

Real-World Examples

Of course, when it comes to convincing you of the problem, nothing would probably drive home more effectively than real stories from real companies. These aren't hypothetical scenarios from a cybersecurity textbook—these are actual cases that made headlines, cost millions, and in some cases, nearly destroyed the companies involved.

Tesla: When One Disgruntled Employee Can Stop Production

In 2018, Tesla learned the hard way that insider threats can bring production to a halt. A disaffected IT employee managed to disrupt the company's entire production line through sabotage [5]. Think about that for a moment—one person, with legitimate access, was able to impact a multi-billion-dollar company's core operations.

But Tesla's insider threat story doesn't end there. In 2023, two former employees leaked sensitive personal data of over 75,000 current and former employees to a foreign media outlet [6]. The leaked information included names, addresses, phone numbers, employment records, social security numbers, customer bank details, and production secrets. It's like having your entire company's diary published in the newspaper—except the diary contains everyone's most sensitive information.

Samsung and the ChatGPT Oops Moment

As we mentioned already, sometimes (actually, research shows that it's less than half), insider threats aren't malicious—they're just well-meaning employees making catastrophic mistakes. Samsung discovered this when employees accidentally revealed trade secrets by using ChatGPT for work-related tasks [5]. They thought they were being productive and innovative. Instead, they were essentially handing their company's secrets to an AI system that could potentially share that information with anyone.

This case exemplifies how the modern workplace, with its AI tools and cloud services, has created new avenues for insider threats to manifest. It's like leaving your house key under the doormat, except the doormat is on the internet and millions of people walk by it every day.

Coinbase: When Outsiders Bribe Insiders

Coinbase faced a different flavor of insider threat when criminals bribed overseas customer-service contractors, leading to a ransomware demand against the crypto exchange [5]. This case highlights how insider threats don't always originate from your direct employees—sometimes they come from third-party vendors and contractors who have access to your systems.

It's a reminder that your security is only as strong as your weakest link, and sometimes that weak link isn't even on your payroll.

A Pattern Emerges

When you study these cases alongside others—like the Yahoo research scientist who stole 570,000 pages of proprietary information minutes after getting a job offer from a competitor [6], or the Microsoft employees who accidentally exposed login credentials to GitHub [6]—specific patterns become clear.

The Departing Employee Threat

The most common insider threat comes from employees who are leaving the company, either voluntarily or involuntarily. It's like a breakup—sometimes it's amicable, but sometimes the departing party wants to take half of everything with them, including things that aren't theirs to take.

Consider the case of Anthony Levandowski, who downloaded thousands of Google's self-driving car files before joining Uber [6]. Google estimated they lost up to $1.5 million due to his theft. Or Samuel Boone from Proofpoint, who stole confidential sales data before joining competitor Abnormal Security [6]. Ironically, Proofpoint's data loss prevention solution failed to prevent its employee from downloading high-value documents to a USB drive.

The Negligent Insider

Once again, not all insider threats are malicious. Sometimes, they're just human error amplified by poor security practices. The Boeing employee who emailed a spreadsheet to his wife for formatting help, unknowingly exposing the personal information of 36,000 coworkers in hidden columns, is a perfect example [6]. The cost? An estimated $7 million in credit monitoring services.

The Social Engineering Victim

Sometimes insiders become threats not through malice or negligence, but because external attackers have manipulated them. The 2020 Twitter hack, where attackers used phone-based spear phishing to compromise employee accounts and take over 130 high-profile accounts, demonstrates how external threats can turn insiders into unwitting accomplices [6].

Startup-Specific Risks

While the examples above come from larger companies, startups and small businesses face unique insider threat challenges. Here are some to think about:

In startups, everyone wears multiple hats and, as a consequence, has access to everything. It's like giving everyone in your house the master key—convenient, but risky. When your team is small and tight-knit, implementing strict access controls can feel like not trusting your own family.

Startups that experience rapid growth often struggle to implement proper security controls fast enough. New employees receive broad access because it's easier than determining precisely what they need. It's like building the airplane while flying it—except the aircraft is carrying your most sensitive data.

Small businesses often can't afford the sophisticated monitoring tools that larger companies use to detect insider threats. They're essentially flying blind, hoping that trust and good intentions are enough to keep them safe.

AI and Remote Work

The COVID-19 pandemic and the rise of AI tools have created new insider threat vectors that didn't exist just a few years ago. Remote work means employees are accessing company data from personal devices and home networks. AI tools like ChatGPT create new avenues for sensitive information to be accidentally leaked. It's like the security perimeter of your company has become as porous as a sponge, with data flowing in and out through channels you might not even know exist.

The Rippling vs. Deel case from 2025 illustrates the increasing sophistication of insider threats [7]. Rippling accused competitor Deel of hiring an employee spy who used legitimate access to platforms like Slack, Salesforce, and Google Drive to exfiltrate sensitive data over four months. This isn't just employee theft—this is corporate espionage at a level that would make Cold War spies jealous.

Conclusion

I hope this article effectively conveys the importance of including the insider threat (whether malicious or not) in your risk assessment. Insider threats represent one of the most significant and underestimated risks facing startups and small businesses today. The statistics are sobering, the real-world examples are frightening, and the potential consequences are severe. But the good news is that with thoughtful planning, reasonable investment, and consistent execution, these threats can be effectively managed.

The real-world cases should serve as a wake-up call for every startup founder and small business owner. Insider threats aren't just a theoretical risk—they're a clear and present danger that can destroy years of hard work in a matter of days or weeks.

But here's the good news: unlike many cybersecurity threats that require expensive technology solutions, insider threats can be significantly mitigated through smart policies, proper procedures, and a culture of security awareness. You don't need a million-dollar security budget to protect yourself—you need to be smart about it.

The key insights to remember:

• Culture is your strongest defense. Technology is important, but a security-aware culture where employees understand their role in protecting the business is your most powerful tool.

• Prevention is cheaper than reaction. The cost of implementing basic insider threat prevention measures is a fraction of the cost of dealing with an actual incident.

• It's not just about technology. While technical safeguards are important, many of the most effective insider threat prevention measures are about people, processes, and policies.

• Assume it will happen. Build resilience into your business so that when you do face an insider threat, you can detect it quickly, respond effectively, and recover completely.

The threat is real, but so is your ability to defend against it. The question isn't whether you can afford to implement insider threat prevention measures—it's whether you can afford not to. Your business, your employees, and your customers are counting on you to get this right. The good news is that with the right approach, you absolutely can.

Read more about it

You can find more help and how to dig deeper in this issue at the links below:

"How to Mitigate Insider Threats: Strategies for Small Businesses." https://www.crowdstrike.com/en-us/cybersecurity-101/small-business/mitigating-insider-threats/

"Insider Threat Mitigation Guide for Small Businesses." https://www.sentinelone.com/platform/small-business/insider-threat-mitigation-guide-for-small-businesses/

"Insider Threat Mitigation Guide." https://www.cisa.gov/resources-tools/resources/insider-threat-mitigation-guide

---

References

[1] IBM Security. "83% of Organizations Reported Insider Threats in 2024." IBM Think Insights. https://www.ibm.com/think/insights/83-percent-organizations-reported-insider-threats-2024

[2] Cybersecurity Insiders. "2024 Insider Threat Report." Gurucul. https://gurucul.com/2024-insider-threat-report/

[3] DTEX Systems. "2025 Cost of Insider Risks: Key Takeaways from Ponemon Institute Report." https://www.dtexsystems.com/blog/2025-cost-insider-risks-takeaways/

[4] StrongDM. "Small Business Cyber Security Statistics." https://www.strongdm.com/blog/small-business-cyber-security-statistics

[5] Tesla (2018), Samsung/ChatGPT, Coinbase, Apple VisionPro cases

[6] Mimecast. "11 Real-Life Insider Threat Examples." https://www.mimecast.com/blog/insider-threat-examples/

[7] Teramind. "Lessons Learned from 9 Real Insider Threat Examples." https://www.teramind.co/blog/insider-threat-examples/

This article is part of an ongoing series on cybersecurity for startups and small businesses. For more practical cybersecurity advice tailored to growing companies, subscribe to my newsletter or follow me on social media.

The Million-Dollar Question: Are You Spending Too Much on Risk Prevention?

Why the smartest risk investment might be knowing when to stop spending.

A Question That Keeps Business Leaders Awake

You are the CISO of your organization, sitting in a boardroom, and someone asks you the ultimate business riddle: "So, how much should we spend to prevent a million-dollar loss?"

Wanting to be of help, your first instinct might be to say, "Well, whatever it takes!" However, there may be a better answer. Here's the thing – mathematics has a surprisingly definitive answer that might shock you: Never spend more than 37% of your expected loss on preventing that loss. I know what you're thinking. "Wait. 37%? That seems oddly specific…" And you're right – it is specific, and there's fascinating science behind it.

The bottom line is that, whether you're a business leader trying to make smart security investments or a cybersecurity professional helping your organization allocate resources wisely, applying this principle will change how you think about risk.

A Universal Concept

In reality, this conversation might extend beyond cybersecurity and is relevant to any decision-makers who need to evaluate how to tackle risk; from supply chain disruptions to workplace safety, the math is the same.

In our specific case, understanding this principle will help you craft compelling business cases and avoid the trap of "security at any cost" thinking, which can damage both your credibility and that of your organization.

If you're still with me, let me explain why this 37% rule isn't just an academic theory and why this piece of practical wisdom may save your organization millions.

Thinking Like Insurance Companies

Insurers have been mastering risk evaluation for centuries. How do they do it? They don't try to prevent every possible loss; instead, they calculate the optimal amount to spend on prevention versus the cost of paying claims. If you like the analogy, they act like professional gamblers who are good at math.

Developed in 2002, the Gordon-Loeb model confirmed what insurance companies had known intuitively: all risk mitigation investments follow the law of diminishing returns. The way it works can be summarized this way: your first dollar spent on security is like buying a deadbolt for your front door – it has a huge impact. Your thousandth dollar might be like adding a motion sensor to monitor your mailbox – technically more secure, but probably not worth the cost!

Here's a practical example:

Consider a data value of €1,000,000, with an attack probability of 15% and an 80% chance of a successful breach. The potential loss is €1,000,000  ×  0.15  ×  0.8 = €120,000. Based on the Gordon-Loeb model, the company’s security investment should not exceed €120,000  ×  0.37 = €44,000

(Source: Wikipedia)

This 37% rule emerges from something called exponential decay functions – basically, the mathematical way of describing how things get less effective the more you do them. It's the same principle that explains why:

• The first slice of pizza is terrific, the fourth slice is okay, and the eighth slice makes you feel terrible

• The first employee you hire transforms your business, but employee number 100 has much less individual impact

• The first security control you implement blocks most attacks, but the 20th control might only catch a few more

The math shows that the optimal spending point always equals 1/e (approximately 0.368, or, in short, 37%), and it seems as fundamental as gravity.

As mentioned at the outset, what makes this principle so powerful: it applies to every type of risk, not just cyber threats. Here are some examples:

• Supply Chain Resilience: Facing a potential $10 million disruption? Don′t spend more than 3.7 million on backup suppliers and redundancy.

• Workplace Safety: Preventing accidents that could cost 5 million? Cap your safety investments at 1.85 million.

• Natural Disaster Preparedness: Building Flood Barriers for a facility worth $50 million? Maximum rational investment: 18.5 million.

• Quality Control: Preventing defects that could trigger 2 million in recalls? Optimal ceiling: 740,000.

The list could go on and on. Think of it like having a universal translator for risk decisions across your entire business.

A Practical Framework

So, the next time you are asked that question, think of this 37% rule. Are we trying to mitigate a 1M risk? It may not be wise to spend more than 370K. You could depict this as a traffic light system for risk spending:

🟡 Yellow Light (Below 37%): You're likely under-investing. Additional expenditure will deliver solid returns. It's like finding money on the ground – pick it up!
🟢 Green Light (Around 37%): You're in the optimization zone. You're likely making wise choices.
🔴 Red Light (Above 37%): Time to pump the brakes. Those dollars might deliver better value elsewhere.

Now, a word of caution: the real world is messier than mathematical models. You can't always quantify expected losses precisely (though you should try). And sometimes regulations force you to spend more than the math would suggest. Also, some investments protect against multiple risks simultaneously, which complicates the calculation.

However, the beauty of the Gordon-Loeb framework is that it imposes mathematical discipline on emotional decisions. Instead of making risk investments based on fear ("What if we get hacked?") or gut feeling ("This feels like enough"), you have an economic foundation for rational decision-making.

Concluding

Even 20 years after its publication, the Gordon-Loeb model remains relevant because it addresses a fundamental business challenge: how to allocate limited resources in the face of unlimited uncertainty.

The 37% rule isn't a rigid spending cap, but rather a mathematical guardrail that helps you think systematically about risk and investment. It's like having a GPS for risk decisions that keeps you from driving off the financial cliff.

Whether you're managing cyber threats, supply chain vulnerabilities, safety hazards, or regulatory risks, the math provides the same guidance: diminishing returns are real, and they kick in sooner than most leaders expect.

How does your organization's risk spending align with the 37% principle? Are you spending smart money on smart risks, or are you paying premium prices for diminishing returns? More importantly, what challenges do you face in quantifying and optimizing risk investments? The math is straightforward, but the implementation is where the real work begins. Remember: the goal isn't perfect security – it's optimal security, and optimal security is as much about knowing when to stop spending as about knowing when to start.

---

A variation of this article appeared first on my LinkedIn Newsletter 'My CISO Adventure” on June 25, 2025.

What losing my Smartphone taught me about Incident Response and Business Continuity

Introduction: The Unplanned Incident

Yes, I lost my smartphone. Now that the dust is settling, I wanted to write about my experience because I believe I've learned some valuable lessons that can be easily applied to any business facing a serious incident. I'm sharing this to highlight the importance of something I often preach (but, as it turns out, still need to be fully implemented in my own life): being prepared for when an incident strikes.

The Moment of Panic

It was Friday afternoon, and I was coming home on the train after a productive meeting at work. Yet, I had a nagging feeling that something was amiss, but I couldn't quite put my finger on what it was.

Saturday morning: "Where is my phone?" After a frantic search in my bag and in the usual places where I leave it when I get home… nothing. My smartphone, my digital lifeline, was gone. The immediate wave of panic was intense – a familiar feeling for anyone who has experienced that sudden, unsettling emptiness in their pocket, or had to respond to a significant incident.

Phase 1: My Personal Incident Response

Of course, the first thing I did was to confirm that the phone was no longer with me. Now that I think of it, this is the first step for any Incident Response team: confirming that the event they are seeing is, indeed, an incident.

My immediate actions, my personal "Incident Response" playbook, kicked in:

• Confirm the incident: I attempted to locate it using its dedicated app. Unsurprisingly, the phone was unavailable (either the battery was dead or it had been turned off by someone else).

• Contain the threat: Assuming the worst-case scenario, I enabled the "lost phone" feature, which remotely disabled virtual cards and locked the device. This swift action was crucial in minimizing potential data compromise.

The incident was contained. But what should I do next?

My safety line:

This trusty old iPhone.

Phase 2: Striving for Business Continuity (or lack thereof)

While the immediate threat was contained, the next challenge was "Business Continuity." In a business context, this means maintaining essential functions during and after a disruption. For me, it meant: how do I keep my life running without my primary device (for a little while, that is)?

My usual "business" (my daily life) relies heavily on that smartphone. Communication, banking, navigation, even just checking the time – it's all there. Without it, I had to scramble for workarounds:

• Communication: I relied on an ancient spare phone to receive calls and texts, which would also be crucial for the next steps.

• Payments/Banking: This was a significant hurdle. My virtual cards were disabled, forcing me to rely on physical cards, but without access to online payments and transfers.

• Navigation: I found myself asking for directions more often and relying on my memory, a stark reminder of how dependent I'd become.

This phase highlighted a critical gap: I didn't have a pre-defined "Business Impact Analysis" (BIA) for my personal life. I hadn't identified my most essential services and how to keep them running if my smartphone were lost. This led to:

• Panic mode: Scrambling to understand and act on priorities in the heat of the moment (hint: never a good idea…)

• Lack of alternatives: Realizing I didn't have a robust way to keep any critical services running if my smartphone were lost.

Phase 3: The Disaster Recovery Journey

In many cases, an incident is so impactful that a full "Disaster Recovery" procedure is invoked. This is about restoring full functionality after a significant loss. For me, this meant getting a new phone and restoring my digital life.

My Disaster Recovery plan (or what I pieced together on the fly) involved:

• Blocking the existing SIM: Easy, but I wished I had the phone number to call readily at hand before…

• Getting a new one: This also went relatively smoothly, thanks to my telco provider, even though they had to open late, as the "guy with the keys” showed up 20 minutes after opening hours (what were the chances, I wonder…)

• Getting an old phone up and running again: Yes, I kept an old phone (and, boy, now am I glad I did)

• Restoring from backup: This is where I hit a significant snag. "Restore… to what?" I had an old phone, but it seemed unfortunately incompatible with the backup (planned obsolescence, anyone?). Luckily, it would still accept the new SIM, so at least the “old” communication system was now back up and running, which was crucial for starting the restoration of some critical services (SMS is still used, despite its weaknesses, but that was a godsend for me).

So, the only obvious solution was to buy another one, but that also proved difficult, as I usually use the virtual cards stored on my phone. Luckily, thanks to the prompt response of my telco provider, having a workable phone number saved the day. I was able to rebuild access to my banking apps through that number, with the help of my bank’s customer service. This was my personal "recovery" phase, slowly bringing my digital life back to full operation.

Post-Mortem and Lessons Learned

After any significant incident, an incident response team should conduct a post-mortem – a formal review of what happened to identify lessons learned and improve processes for the next time. And, when it comes to lost phones, there will likely be a next time…. So, what were my lessons? Here they are:

• Create an actual 'lost phone' playbook: This would help the incident response team (me!) with what needs to happen in order and avoid the panic that sets in.

• Having a ready-to-use list of contacts, including emails, phone numbers, and websites for essential services, would significantly aid recovery.

• Perform a personal BIA: Identify the services that should be kept running continuously. In my case, I realized it was anything related to money, so bank apps (both personal and business) were top priority.

Building Resilience: My Post-Mortem Actions

While I am still mulling over whether I should create an actual playbook (it might be too geeky even for me!), this is what I did do:

• While I was restoring my services, I kept a list of actions that I needed to carry out, along with the contact information for the services I had to call, in case I needed to refer to them again (some would say that is the beginning of a plabook)

• I have installed and validated all the money-related apps on a backup device (my trusty iPad), which should make it easier to keep these services running the next time.

Wrapping up

This unexpected incident taught me that even in our personal lives, the principles of incident response, business continuity, and disaster recovery are not just corporate jargon; they are essential for everyday life. They are practical frameworks for navigating the inevitable disruptions of our increasingly digital world.

What's your incident response plan for a lost device? How would you maintain your 'business continuity' if your digital lifeline suddenly vanished? Proactive planning is key to resilience, both personally and professionally.

Breaking Into Cybersecurity: A Realistic Guide for Career Changers

A straightforward look at what it really takes to start a cybersecurity career, based on nearly two decades in the field.

The Reality Check You Need

Let me start with something most career guides won't tell you: breaking into cybersecurity isn't as simple as taking a bootcamp and landing a six-figure job. After watching hundreds of people transition into this field over the past 18 years, I've learned that the most successful career changers are those who understand what they're getting into.

Cybersecurity isn't like the movie "The Net" or "War Games" (yes, I am that old!)

You won't be typing furiously in a dark room while dramatic music plays in the background. But here's what it is: one of the most rewarding, challenging, and future-proof career paths you can choose.

Cybersecurity isn't the Hollywood thriller you might imagine. There's no dramatic music playing while you type furiously to stop a cyber attack in progress. Most days, you'll spend time reviewing logs, updating documentation, attending meetings about compliance requirements, and explaining to colleagues why they can't use that convenient new app they found online.

However, what makes it worthwhile is that you're solving real problems that matter. When you prevent a ransomware attack, you're protecting someone's livelihood. When you secure a healthcare system, you help ensure that patient care continues uninterrupted. The work has a genuine impact, and that's something not every career can offer.

What Employers Want

The cybersecurity skills gap is real, but it's not what most people perceive it to be. We're not desperately hiring anyone with a security certification. I am looking for individuals who can think critically, communicate effectively, and adapt quickly to new challenges and emerging technologies.

Here's what I would look for when hiring entry-level security professionals:

• Problem-solving ability matters more than technical knowledge. I can teach someone how to use a security tool, but I can't teach them how to think through complex problems systematically. During interviews, I often present scenarios like "A user reports their computer is running slowly, and you notice unusual network traffic. Walk me through your investigation process." The best candidates don't jump to conclusions; they ask clarifying questions and outline a methodical approach.

• Communication skills are critical. You'll spend significant time explaining technical concepts to non-technical stakeholders. If you can't clearly articulate why a security control is necessary or what a particular risk means to the business, you'll struggle in most cybersecurity roles.

• Curiosity and continuous learning are essential because the threat landscape is constantly evolving. The candidate who mentions setting up a home lab to experiment with different security tools, or who can discuss a recent security incident they have read about, demonstrates the mindset I am looking for.

A basic technical foundation is, of course, necessary, but it doesn't have to be extensive. Understanding how networks function, having some familiarity with operating systems (both Windows and Linux), and being familiar with basic scripting concepts will serve you well. You don't need to be a programmer, but you should be comfortable with technology.

The Most Realistic Entry Points

Based on what I've observed, here are the paths that work for career changers:

• Security Operations Center (SOC) Analyst remains the most common entry point, but the role has evolved significantly. Modern SOC analysts spend less time staring at dashboards and more time investigating alerts that have been pre-filtered by automated systems. You'll learn to distinguish between false positives and genuine threats, document incidents accurately, and escalate them appropriately. The work can be repetitive, but it provides excellent exposure to different types of security tools and attack patterns.

• IT Support with Security Responsibilities often provides a smoother transition for people coming from general IT backgrounds. Many organizations are adding security components to traditional IT roles. You might find yourself managing endpoint protection software, helping with security awareness training, or assisting with compliance audits. This path enables you to develop security skills gradually while leveraging your existing technical expertise.

• Compliance and Risk Analyst positions are well-suited for individuals with backgrounds in auditing, project management, or regulatory compliance. These roles focus on ensuring organizations meet security standards and regulations. While less technical than other security positions, they provide valuable exposure to security frameworks and business risk management.

• Cybersecurity Specialist in Non-Tech Industries can be an excellent option. Healthcare organizations, manufacturing companies, and financial services firms often require security professionals who understand the specific industry challenges they face. Your domain knowledge in healthcare, finance, or manufacturing can be just as valuable as pure security expertise.

Building the Right Skills

The certification landscape in cybersecurity is overwhelming, and much of the advice you'll find online is either outdated or overly focused on advanced certifications that won't help you get your first job. For entry-level positions, focus on these certifications in order of priority:

• CompTIA Security+ remains the most widely recognized entry-level certification in the industry. It covers broad security concepts without going too deep into any particular area. More importantly, it's required for many government and contractor positions, which can provide stable entry points into the field.

• CompTIA Network+ or equivalent networking knowledge is crucial because security is fundamentally about protecting network infrastructure and data flows. You don't need to be a network engineer, but understanding how data moves through networks, what firewalls do, and how VPNs work will make you much more effective in any security role.

• Cloud fundamentals are becoming increasingly important as organizations migrate their infrastructure to cloud platforms. AWS, Azure, and Google Cloud all offer foundational certifications that demonstrate basic cloud literacy. Choose based on what's most common in your target job market.

• Beyond certifications, hands-on experience matters more than credentials. Set up a home lab where you can experiment with security tools. Install a hypervisor, such as VirtualBox, and create virtual machines. Practice using tools like Wireshark for network analysis, Nmap for network scanning, and basic Linux command-line operations.

The Salary Reality

Let's address the elephant in the room: cybersecurity salaries are good, but entry-level positions don't start at $100,000 unless you're in a high-cost-of-living area or have significant relevant experience. Realistic salary expectations for entry-level positions (you can read these figures either in $ or Euros):

• SOC Analyst: 45,000-65,000 in most markets

• Junior Security Analyst: 50,000-70,000

• Compliance Analyst: 55,000-75,000

• Security Specialist (non-tech industry): 60,000-80,000

These numbers increase significantly with experience and additional certifications. After 3-5 years, you can expect to earn 80,000-120,000, depending on your location and specialization. Senior positions and management roles can command salaries of 150K or more in many markets.

The key is to view your first cybersecurity job as an investment in your future earning potential, rather than expecting immediate financial rewards.

Common Mistakes to Avoid

Don't try to learn everything at once. Cybersecurity is a broad field, and trying to master penetration testing, incident response, compliance, and risk management simultaneously will leave you overwhelmed and unfocused. Pick one area to start with and build depth before expanding.

Don't ignore the business side. Technical skills alone won't make you successful in cybersecurity. Understanding how businesses operate, what drives decision-making, and how to communicate risk in business terms is crucial for career advancement.

Don't expect immediate excitement. Your first cybersecurity job will likely involve routine tasks, documentation, and learning organizational processes. The exciting incident response and threat hunting work comes after you've proven you can handle the fundamentals reliably.

Don't underestimate soft skills. The stereotype of the antisocial security expert working alone in a dark room is outdated. Modern cybersecurity is collaborative work that requires strong communication, project management, and relationship-building skills.

Making the Transition

If you're serious about transitioning into cybersecurity, here's a practical timeline:

• Months 1-3: Build foundational knowledge through online courses, books, and hands-on practice. Focus on networking fundamentals and basic security concepts. Start working toward your Security+ certification.

• Months 4-6: Set up a home lab and begin practicing with security tools. Join local cybersecurity meetups or online communities to connect with like-minded individuals. Start tailoring your resume to highlight the transferable skills you've developed in your current role.

• Months 7-9: Begin applying for entry-level positions while continuing to build skills. Consider contract or part-time opportunities that might provide easier entry points—network with professionals in your target organizations.

• Months 10-12: Refine your approach based on interview feedback. Consider additional certifications or training based on the specific requirements you're seeing in job postings.

This timeline assumes you're dedicating 10-15 hours per week to learning and skill development while maintaining your current job. Some people move faster, while others need more time; however, having realistic expectations helps maintain motivation during the transition period.

The Bottom Line

Let me let you into a secret…

The most successful cybersecurity professionals aren't necessarily the most technical. They're the ones who can explain complex problems in simple terms. Work on this.

Cybersecurity presents genuine career opportunities for individuals willing to invest the time and effort required to develop relevant skills. The field requires individuals who can think critically, communicate effectively, and adapt to evolving threats and challenges. It's not a get-rich-quick scheme, but it is a field where dedicated professionals can build rewarding, well-compensated careers while doing work that genuinely matters.

The key is approaching the transition with realistic expectations, focusing on building practical skills, and understanding that your first cybersecurity job is the beginning of your journey, not the destination. With persistence and the right approach, you can successfully make the transition from whatever field you're in now to a meaningful career in cybersecurity.

---

I am a cybersecurity consultant with about 20 years of experience helping European organizations establish resilient security programs. I am the founder of BARE Cybersecurity and hold CISSP and CCSP certifications. Connect with me on LinkedIn for daily cybersecurity insights and career guidance.

The Modern CISO: from Tech Geek to Business Consultant

Why do cybersecurity leaders need to trade their technical toolbelts for business suits (but keep the tools handy)?

The Great CISO Transformation

Imagine that you are a Chief Information Security Officer (CISO) at a dinner party, and someone asks what you do. Ten years ago, you might have said, "We're like security guards who make sure hackers don't break into computer systems." Today? Well, that would be like saying a symphony conductor "just waves a stick around”.

To continue with the analogy, the modern CISO is more akin to the conductor of a complex orchestra, where the violins represent your IT department, the brass section represents your compliance team, and the percussion is your incident response crew, ready to jump into action when things get loud :)

Having spent years helping organizations build their cybersecurity programs from the ground up, I've witnessed this slow transformation. The CISOs who thrive today aren't just the ones who can spot a phishing email from a mile away (though that might help); they are the ones who can explain to the CEO why that new cloud project is like “moving from a house with deadbolts to a smart home with facial recognition” – potentially more secure, if you set it up right.

Here's the thing about cybersecurity leadership that might surprise you: it's no longer only about technology. It is — and, I would argue, mostly — about people, and having them follow the right processes. You've heard this three-legged stool already: People, Process, and Technology.

When any of these fail, your organization will be the equivalent of the owners of a house in the neighborhood that close all the windows but leave its front door wide open with a sign saying "valuables inside”: just waiting for the "right” person to notice.

A Business Translator

In this sense, CISOs are 'translators', who, instead of converting French to, say, English, they're translating the complex lingo coming from their tech teams (e.g., "We have a critical vulnerability in our authentication system") into something that executives would understand (e.g., "There's a chance someone could walk through our digital front door without showing ID, and here's what we should do about it.").

This translation skill is crucial because:

• Board Members Speak Business, Not Binary: When you tell a board member about a ‘SQL injection attack', their eyes glaze over faster than a donut in a bakery window. But tell them, "Someone could potentially access our customer database the same way a pickpocket might rifle through someone's wallet," and suddenly you have their attention.

• A Budget Conversation Needs Context: Requesting $500,000 for "enhanced endpoint protection" sounds like tech jargon and won't get you far. Explaining that it's like “upgrading from basic door locks to smart locks that can tell you who's trying to get in and when” is a conversation any homeowner (and board member) can understand.

• Understanding Risk Requires Real-World Analogies: Cyber risk assessments are similar to home insurance evaluations. You assess your neighborhood (the threat landscape), check your locks and alarms (your security controls), and determine how much coverage you need based on what you could lose (your assets) if something goes wrong (the risk).

The CISO as Chief Relationship Officer

If you prefer another analogy, consider this: being a successful CISO is like hosting an important dinner party; you need to ensure that everyone gets along, feels heard, and leaves satisfied! So, who are the invitees to this party?

Your CEO: This is where you need to muster patience, clear communication, and the ability to explain why spending money on things that "prevent bad things from happening” is just as important as “spending money on things that make good things happen”.

Your CFO: CFOs are like that friend who always asks, "Do we really need the premium cable package?" when you're trying to explain why your cybersecurity investments matter. Your job is to show them that good security is like good insurance – you hope you never need it, but you'll be really glad you have it when you do.

Your CTO: This relationship should be like a buddy cop movie – you're both trying to solve the same case (keeping the organization safe and functional), but you approach it from different angles. They're thinking about what's possible; you're thinking about what could go wrong.

Going beyond individuals, you should also make sure you keep a good relationship with these departments as they will help you support and promote your cybersecurity strategy:

• HR: They care about people and policies, so frame security in terms of protecting employees, the company, and creating a safe work environment.

• Sales: They want to move fast and close deals, so show them how good security can be a selling point – customers trust companies that take data protection seriously.

• Marketing: They're all about the brand, so help them understand that a security incident is like a costly, very negative advertising campaign that you definitely don't want to run.

Play Chess, not Checkers

Finally, if I may, I have one last analogy. Successful CISOs think like chess players: they're not just looking at the current move, but considering three, four, even five moves ahead. So, while others focus on today's fire drill, they plan for tomorrow's challenges. How?

Threat Scenarios: You are like a meteorologist for cyber threats; even if you can't predict exactly when the storm will hit, but you can prepare for different types of weather and have the right gear ready.

Cybersecurity Strategy: Think of it like buying a house: you don't just consider your current needs; you think about whether it'll work if you have kids, if you work from home more, or if your elderly parents need to move in. So, your security strategy needs the same forward-thinking approach.

Technology Evolution: Staying ahead of technology trends is like trying to predict fashion – you need to spot the trends early enough to prepare, but not so early that you invest in the cybersecurity equivalent of parachute pants.

The Practical Path Forward

You are not a CISO yet, but want to become one? You need to hone different skills, but, to keep things simple, here are three areas all equally important you should pay attention:

Technical skills: Of course, you still need to possess technical expertise. You can't fake your way through a conversation about encryption or network security. However, remember that you're not trying to win the technical Olympics – you need to be competent enough to make sound decisions and ask the right questions.

Business Skills: Learn to read financial statements, understand business models, and speak the language of profit and loss. Take a business course, read business books, or find a mentor who can translate business-speak for you.

Communication Skills: This is often where aspiring CISOs, who come from a technical background, hit a wall—practice explaining technical concepts to your non-technical friends and family. If you can convince your grandmother of the importance of two-factor authentication, you can probably handle a board presentation.

Building Your Experience Portfolio

So, how would I develop these skills while I am waiting for your CISO opportunity? I am glad you asked…

Volunteer for Cross-Functional Projects: You get to know everyone, understand different perspectives, and build relationships that will serve you well later.

Lead Incident Response: Nothing teaches you crisis management like actually managing a crisis. It's like learning to drive in a snowstorm – terrifying at first, but incredibly educational.

Practice Executive Communication: Start a blog (hint, hint), give presentations, or volunteer to explain technical topics to non-technical groups. It's like learning a new language – the more you practice, the more fluent you become.

The Bottom Line

Becoming a strategic CISO is akin to evolving from a security guard to a security consultant and then to a business advisor who specializes in preventing bad things from happening to good organizations. It's not just about knowing technology; it's about understanding people, business, and how to protect what matters most to the organization.

The organizations that will thrive in our increasingly digital world are those led by people like you, who can bridge the gap between technical possibility and business reality and start building those bridges now. Your future self (and your organization) will thank you.

Every expert was once a beginner who refused to give up. The cybersecurity field needs more leaders who can make complex topics accessible, build trust across organizations, and keep us all a little bit safer in our digital lives.

---

These insights come from years of helping organizations navigate the sometimes choppy waters of cybersecurity maturity. The best part of this work? Watching technical professionals transform into business leaders who can protect what matters most while enabling what matters next.