%20(62).png)
Key Takeaways:
- Incident response involves high-stakes decisions about containment, downtime, customer communication, legal obligations, and recovery, so it calls for clear leadership as well as technical expertise.
- NIST SP 800-61 Rev. 3 distinguishes two roles: leadership manages the response and may decide on high-impact actions, while incident handlers investigate, contain, and restore.
- A vCISO leads security before, during, and after an incident: preparing the team for when it happens, coordinating the response, and following through on fixes.
- A vCISO doesn't replace forensic responders, legal counsel, communications teams, or executives who accept material business risk.
- In SecureLeap's experience, the costliest gap in an incident is unclear ownership, which slows down every decision the team needs to make. It's far easier to sort out before an incident than in the middle of one.
When a security incident hits a startup, someone needs to lead the response, and that person isn't always the one running the forensic analysis. A vCISO's role in incident response is to provide security leadership throughout the incident.
In practice, that means preparing the plan, assigning decision owners, bringing in the right people, keeping leadership informed, and closing the gaps the incident revealed.
Many startups without a full-time CISO only discover their ownership gaps during an incident: engineering is busy containing the threat, the CEO is asking about customer notification, and the team realizes nobody has the authority to take production offline. This article explains where a vCISO fits in that picture, and where their role ends.
Incident response: a leadership and a technical issue
Containment, eradication, and recovery are technical activities. Still, the decisions around them carry business consequences: whether to accept customer downtime to isolate a system, when to involve legal counsel, what to tell customers, and how much residual risk the company can live with while it recovers.
In SP 800-61 Rev. 3, published in April 2025, NIST describes the leadership team as responsible for incident response, allocating funding, and potentially holding decision-making authority over high-impact actions (such as shutting down or rebuilding critical services). Incident handlers, by contrast, verify that an incident occurred, collect and analyze evidence, limit damage, find root causes, and restore operations.
In a large company, a full-time CISO usually connects leadership and the technical team. But in a startup without one, that connection is often missing. That can mean engineers have to make containment calls with business consequences they don’t understand, and executives have to make business calls without understanding the technical picture. A vCISO fills that gap as the senior security leader who links the two.
Incident response vs. cyber crisis management
Not every security incident becomes a business crisis. A phishing email reported by an employee, or a blocked login attempt, can be handled by the technical team following the runbook, for example.
It does become a crisis when it's material enough to affect customers, operations, legal exposure, revenue, or the company’s reputation. At that point, the response involves the whole executive team, and the decisions go well beyond security. The vCISO is part of that broader executive response, bringing the security perspective and keeping the technical work connected to leadership's decisions, without becoming the sole decision-maker.
Clear severity levels are what make this distinction work. They tell the team when an incident stays within Engineering and when it needs to reach leadership.
What a vCISO does before an incident
Most of a vCISO's value in incident response is already there, even before anything goes wrong.
Keep incident response plans realistic
CISA's Incident Response Plan Basics describes an incident response plan as a written document, formally approved by senior leadership, that clarifies roles and responsibilities. That plan only helps if it works according to the company's real systems, teams, vendors, legal contacts, customer obligations, and escalation paths.
The vCISO makes sure that plan names who gets called at 2 a.m., identifies the outside technical firm that would investigate a compromise, and reflects contractual commitments (such as how quickly enterprise customers expect to be notified).
The plan should also list stakeholders who can be easy to forget under pressure (such as the board, key investors, and critical partners).
CISA recommends having an attorney review the plan, keeping printed copies of it and the contact list (since email, chats, and document storage could be down during an incident), and updating it quarterly to keep up with changes in the business.
Define severity levels and decision rights
The vCISO sets severity levels and, with leadership, agrees on who has the authority to isolate systems, shut down services, engage external responders, or escalate to executives.
Writing down these decision rights ahead of time prevents the most common delay in a real incident: the team knows what to do, but is waiting for permission from someone who isn't even sure it's their call to make.
Run realistic tabletop exercises
A tabletop exercise is a role-playing session in which a facilitator presents a scenario, and the team works through how each person would respond. It tests the plan against realistic situations (such as compromised credentials, a cloud storage exposure, ransomware, or a breach at a key vendor).
CISA's Tabletop Exercise Packages are a useful starting point for scenarios. The vCISO designs and facilitates these exercises, then turns the gaps they expose into owned tasks. I often recommend running at least one tabletop exercise a year with leadership involved, plus one after major changes to your architecture or team.
Prepare leadership for the decisions they will face
Executives shouldn't learn about their role in an incident during the incident.
A vCISO walks leadership through the calls they may need to make (accepting downtime, approving external spend, authorizing customer notification, and accepting residual risk), so those calls don't default to Engineering or IT. That preparation also includes a holding statement, a short pre-approved response for a reporter or customer who hears about an incident before the company is ready to share details.
What a vCISO does during an incident
When an incident is underway, the vCISO's job is to keep the response organized and the decisions moving.
Establish incident command
A vCISO helps set up a clear command structure. CISA's Incident Response Plan Basics suggests three roles:
- Incident Manager: Leads the response, manages communication flows, updates stakeholders, and delegates tasks, without performing technical duties.
- Tech Manager: Serves as the subject matter expert and brings in other internal or external technical experts.
- Communications Manager: Handles reporters, public updates, and external stakeholders.
In a startup, a vCISO often fits the Incident Manager role or supports whoever holds it, while an engineering lead acts as Tech Manager. Without that structure, several people end up making overlapping decisions, or nobody makes them at all.
Translate technical findings into business impact
Leadership doesn't need every log entry, but to know: which customers or systems are affected, what the options are, what they each cost in downtime or exposure, and what the team recommends. The vCISO summarizes technical findings in that format and keeps executives informed without flooding them with irrelevant details.
Coordinate the right specialists
A serious incident can involve internal engineering, forensic or incident response providers, legal counsel, cyber insurance, communications, vendors, and executive leadership. The vCISO coordinates these parties and keeps them aligned on the same facts and priorities.
Maintain decision discipline
Under pressure, teams can lose track of information and decisions. The vCISO keeps a running record of: what’s known, what’s still uncertain, what has been approved, what risk is being accepted and by whom, and what needs escalation. That record also becomes essential for the post-incident review, insurers, and any regulatory or customer follow-up.
Example: an escalation decision in a credential compromise
Let’s assume a SaaS startup discovered that a cloud access key was exposed in a public code repository. The logs show the key was used to read data from a storage bucket that holds customer exports.
The incident handlers revoke the key and start investigating what was accessed. The open question is whether to take the customer export feature offline while they confirm that no other credentials were exposed, which would mean visible downtime for customers.
The vCISO frames the decision for leadership: the evidence so far, what remains uncertain, the risk of keeping the feature online, the customer impact of disabling it, and the recommendation. The CEO makes the call, legal counsel starts assessing notification obligations based on what was accessed, and the vCISO records the decision and the residual risk that leadership accepted.
What a vCISO does after an incident
Incident response doesn't end when systems are restored. After the fact, the vCISO ensures the incident improves the company's security posture, instead of repeating itself.
- Post-incident review: Lead or coordinate a blameless review focused on what failed, what worked, and why decisions took as long as they did. CISA notes that incidents are rarely the result of one person's action and are almost always the result of a failure of the overall system.
- Owned remediation: Turn lessons learned into tasks with owners and deadlines, so the review doesn't become a report nobody reads.
- Updated risk and controls: Update the risk register, security roadmap, controls, runbooks, and escalation model based on what failed.
- Prioritization: Help leadership prioritize remediation based on business impact and the likelihood of recurrence, since not every finding is equally urgent.
- Reporting: Bring material lessons and residual risk back to executives or the board when appropriate, and share the findings with staff to strengthen the company's security culture.
Who does what: vCISO vs. incident handlers, legal, and leadership
A vCISO isn't automatically the SOC, the digital forensics team, breach counsel, the PR team, or the executive who accepts business risk.
Depending on the engagement, the vCISO may coordinate all of these parties and lead the security response, but they each keep their own responsibilities.
Incident response planning is also different from the work of a SOC or MDR provider. A SOC or MDR service monitors and responds to alerts. A vCISO makes sure the company knows what to do, and who decides, when one of those alerts becomes a real incident. Many startups need both, and NIST notes that when a third party performs incident response activities, the division of responsibilities should be clearly defined in the contract.
Make sure your next incident has a leader before it happens
In our experience, the costliest gap during an incident is often unclear ownership, which can lead to slow decisions and a team discovering under pressure that nobody knows who's authorized to do what. By then, every hour of confusion can mean more downtime, more exposure, and harder conversations with customers.
SecureLeap's vCISO service gives your startup a senior security leader who owns incident readiness before a crisis and leads the security response when it happens. We define severity levels, decision rights, run tabletop exercises that expose gaps early, and, when an incident hits, coordinate your engineers, external responders, legal counsel, and executives around clear decisions. Specialized forensic or legal work may still require dedicated providers, and we help you identify and engage them before you need them.
In a crisis, you need someone who has been there before. Marçal Santos brings more than 20 years of cybersecurity leadership experience, including security programs at Aircall, Citibank, and Talkdesk. Marçal knows what to prioritize when everything feels urgent, what information leadership needs to make a decision, and how to keep technical teams and executives moving in the same direction.
Not sure who would lead your next incident? Book a free 30-minute call with SecureLeap to review your incident readiness and who decides what.
FAQ: Frequently Asked Questions
Who should lead incident response in a startup?
A senior security leader, such as a CISO or vCISO, should lead incident response, working alongside the executive team. The technical work stays with the incident handlers, while executives make the high-impact calls.
Does a vCISO perform digital forensics?
Not necessarily, since a vCISO provides security leadership, preparation, and coordination. Digital forensics and hands-on containment are usually performed by internal engineers or a specialized incident response provider, which the vCISO helps select and coordinate.
Who decides whether to notify customers after an incident?
Executive leadership should decide, based on advice from legal or privacy counsel on notification obligations and from the vCISO on what happened and which data or systems were affected. Contractual commitments to enterprise customers can also set notification expectations.
What should an incident response plan include from a leadership perspective?
From a leadership perspective, an incident response plan should define severity levels, decision rights, escalation paths, and contact details for internal owners, external responders, legal counsel, insurers, and key vendors. It should also specify who approves high-impact actions such as shutting down services, and who manages customer and external communication. CISA recommends that senior leadership formally approve the plan and that key people keep a printed copy with the contact list.
How often should a startup run incident response tabletop exercises?
At least once a year with leadership in the room, according to SecureLeap's recommendation, and again after significant changes to your systems, team, or vendors. CISA also recommends reviewing the incident response plan itself quarterly. Each exercise should end with owned actions to close the gaps it exposes.
