Engagement 03

Incident Readiness Assessment

“If a serious security incident happens tomorrow, what will actually happen in the first four hours?”

Lion Sec walks your team through realistic incident scenarios and finds the points where the response would stall: an unclear decision-maker, a missing authority, an evidence source nobody can reach. You get a response model adapted to your organization, not a generic policy.

Duration
10–15 business days
Access
No internal access required
Format
Up to 5 interviews, 5 scenarios, 5 playbooks
The problem

Tools do not respond to incidents. People and decisions do.

Many companies already have monitoring, security controls and technically strong engineers. When a real incident starts, the response is still improvised — because the questions that need answering in the first minutes have never been answered in advance.

Who coordinates? Who may disable an account, isolate a workload or restrict production? Which evidence is checked first, and which must be preserved? When are management, legal, privacy or customers involved? When is the incident actually contained?

If those decisions are made while the incident is developing, even a straightforward compromise stays active longer than it needs to — and the additional business disruption, data exposure and cost come from the delay, not from the attack itself.

It is for you if

You already have security controls and monitoring in place

Your company has invested in security tooling, but the processes for responding when something actually happens are still immature.

Incident response is not a dedicated function

Responsibility sits with your CTO, Head of Engineering, IT team, or first security specialist rather than a dedicated response team.

Your response capability depends on individual people

A few technical employees know what to do during an incident, but that knowledge has not been turned into a repeatable company-wide process.

You need confidence that your team can actually respond

You have monitoring, people, and tools — but no evidence that they will work together effectively during a real incident.

Particularly relevant when

An incident or near miss exposed gaps in your response

Responsibilities, escalation paths, communications, or next steps became unclear when they were actually needed.

Your company is growing or becoming a more attractive target

You are adding critical systems, handling more sensitive data, or can no longer rely on an informal response process.

External stakeholders are asking about incident readiness

Customers, auditors, insurers, or partners increasingly expect you to demonstrate how incidents are detected, escalated, and handled.

Your incident response has never been tested

You may have documentation or playbooks, but no realistic exercise has shown whether your team can execute them under pressure.

What Lion Sec does

How the engagement runs

Existing capabilities → incident scenarios → response gaps → playbooks → priorities → readiness roadmap.

  1. 01

    Assess

    Review of existing incident response documentation, organizational responsibilities, high-level architecture, available security capabilities and escalation processes, together with up to five stakeholder interviews.

  2. 02

    Simulate

    Representative incident scenarios are walked through with the people who would actually respond.

    • Compromised employee or administrator account
    • Leaked production secret
    • Cloud account compromise
    • Compromised endpoint
    • Suspected sensitive data exposure
  3. 03

    Identify gaps

    Every point where the response would slow down, become ambiguous or fail is recorded across people, process and technology.

    • Governance: who commands, who may disable accounts, stop services or escalate
    • Detection and triage: alert ownership, declaration criteria, severity assignment
    • Containment: revoking identities, sessions, credentials, tokens and integrations
    • Investigation: which evidence sources answer which questions
    • Escalation and communication: internal, customer, regulator and provider paths
    • Recovery and closure: containment, recovery and closure criteria
  4. 04

    Build the response model

    Roles, responsibilities, escalation paths, severity classification, playbooks, evidence requirements and a remediation roadmap — written for your environment and your team size.

What you provide

No internal technical access is required. You provide documentation and access to the people who would respond:

  • High-level architecture diagram and list of critical business services
  • Primary cloud and SaaS platforms
  • Description of existing security monitoring and tooling
  • Existing incident response policies or playbooks, if any
  • Organisational structure and the roles that would take part in a response
  • High-level description of available logging capabilities
  • Backup and recovery process
  • External providers involved in incident response, if applicable
What you receive

Deliverables

The output is an operating model, not a policy document: material the team can open during an incident.

Executive Summary

Overall readiness rating, readiness per capability area, the most significant operational gaps, the highest-risk dependencies and the top remediation priorities.

Incident Readiness Assessment Report

Preparation, detection, triage, containment, investigation, eradication, recovery and post-incident activity. Each gap states the affected scenario, the risk, the potential consequence and the recommendation.

Roles, escalation and classification matrices

Incident Commander, technical lead, security lead, business lead, communication lead and legal or privacy contact, with escalation thresholds, decision-making authority and a severity model from SEV-1 to SEV-3.

Incident response playbooks

Three to five playbooks for the scenarios most relevant to you, each covering triggering conditions, immediate actions, investigation steps, containment, escalation criteria, evidence requirements, recovery criteria and the actions to avoid.

Incident Evidence Checklist

What must be preserved for common incident categories — authentication and MFA events, session history, administrative actions, cloud audit logs, IAM changes, workload logs and credential metadata.

Assumptions and Unknowns Register

Client statements are recorded as statements, with the technical validation each one still requires. Process findings are never presented as verification of your production environment.

90-Day Incident Readiness Roadmap

P0 immediate through P3 at 90 days. Each item names the gap it addresses, the expected risk reduction, the implementation effort and the recommended owner.

The engagement closes with a findings workshop with the stakeholders who took part.

Standard package

The standard engagement includes:

  • Up to 5 stakeholder interviews
  • Review of existing incident response documentation
  • Review of the high-level system architecture
  • Assessment of one primary production environment
  • Up to 5 incident scenarios and up to 5 playbooks
  • Executive summary, full report and 90-day roadmap
  • One final findings workshop
Not included

The assessment evaluates preparedness. It does not include, and does not claim to verify:

  • Active incident response, digital forensics or malware analysis
  • Penetration testing and vulnerability scanning
  • Technical configuration audit or validation of production security controls
  • Deployment of monitoring or security tooling
  • Legal or regulatory advice
  • Business continuity implementation and disaster recovery testing

Scope boundaries are stated in the report as well, so findings are never mistaken for verification of something that was not examined.

After the engagement

What changes

Before

The company has security tools and capable engineers, but its response to a serious incident depends on improvisation and on what one or two people happen to know.

After

Your team knows who does what, who makes critical decisions, and how to act during the first hour of an incident — with clear escalation paths, evidence-preservation procedures, and a prioritized plan to close the remaining gaps.

Why this is worth doing now

Incident readiness is the one security capability that cannot be acquired during the event it is needed for. The work is inexpensive while nothing is happening, and unavailable once something is.

Next step

Talk through your situation before committing to anything.

An introductory call establishes whether the Incident Readiness engagement is the right answer for your company right now, what it would cover in your environment, and what you would have at the end of it.