Dealing with cyber incidents is a big deal. It’s not just about fixing the immediate problem, but also about making sure it doesn’t happen again. This whole process, known as incident response, involves a lot of moving parts. From figuring out what went wrong to getting back to normal, and then learning from it all, there’s a structured way to handle these situations. Having a solid plan makes a huge difference when things go sideways.
Key Takeaways
- Having clear roles and communication plans is the first step in effective incident response. Everyone needs to know who does what and how to talk to each other when an incident happens.
- Spotting and understanding an incident quickly is super important. You need to figure out if an alert is real, how widespread the problem is, and how serious it is to decide on the right actions.
- Stopping an incident from spreading is the next big move. This means isolating affected systems and blocking bad actors from causing more damage.
- Once contained, you have to get rid of the bad stuff and fix what’s broken. This includes removing malware, patching security holes, and resetting any compromised accounts.
- Getting back to normal operations and making sure the business can keep running is the final stage. This also involves looking back at what happened to make the whole incident response process better next time.
Foundations Of Incident Response
Before diving into the nitty-gritty of handling a cyber incident, it’s important to have a solid groundwork in place. Think of it like building a house; you wouldn’t start putting up walls without a strong foundation. For incident response, this means having clear structures and plans ready to go. This section covers the bedrock principles that make your response efforts effective and efficient when things go sideways.
Defined Roles And Escalation Paths
When an incident strikes, the last thing you want is confusion about who does what. Having clearly defined roles means everyone knows their responsibilities, from the initial alert handler to the executive decision-makers. This clarity prevents tasks from being missed or duplicated. Equally important are the escalation paths. These are the pre-determined routes for information and decisions to travel up the chain of command. Knowing exactly who to inform and when, based on the incident’s severity, helps speed up the response and ensures the right people are making the right calls.
- Incident Response Team (IRT) Lead: Oversees the entire response effort.
- Technical Analysts: Investigate and contain the incident.
- Communications Lead: Manages internal and external messaging.
- Legal Counsel: Advises on legal and regulatory obligations.
- Executive Sponsor: Provides high-level support and decision authority.
Communication Protocols And Decision Authority
How information flows during a crisis is just as critical as the technical actions taken. Establishing communication protocols means you have agreed-upon methods and channels for sharing updates, findings, and requests for action. This could involve secure chat channels, regular status calls, or a dedicated incident management platform. Alongside this, clear decision authority is vital. Who has the final say on critical actions, like taking a system offline or engaging external help? Defining this upfront avoids delays and indecision when time is of the essence. Without these defined lines, a minor incident can quickly spiral out of control due to miscommunication and a lack of clear leadership.
Establishing these protocols isn’t just about having a plan; it’s about practicing them. Tabletop exercises and simulations help teams get comfortable with the communication flow and decision-making processes, making them more effective under real pressure.
Response Planning For Consistency
Having a documented incident response plan (IRP) is non-negotiable. This plan acts as a playbook, outlining the steps to take for various types of incidents. It ensures that responses are consistent, regardless of who is on duty or how many incidents are happening simultaneously. A well-structured IRP covers everything from initial detection and assessment to containment, eradication, recovery, and post-incident review. It should be a living document, regularly reviewed and updated to reflect changes in the environment, threats, and organizational structure. This consistency builds confidence and reduces the likelihood of critical errors during high-stress situations.
Incident Identification And Assessment
The first real step in handling any cyber issue is figuring out what’s actually going on. You can’t fix a problem if you don’t know what it is, right? This part is all about spotting those suspicious activities and then getting a handle on how bad they might be. It’s like being a detective, but for computers.
Validating Alerts And Determining Scope
So, your security tools are buzzing. Great. But are they actually telling you about a real problem, or is it just a glitch in the system? You need to check those alerts. Sometimes, they’re just noise, like a smoke detector going off because you burned toast. But other times, that toast burning is actually the start of a kitchen fire. You have to figure out which is which. Once you confirm it’s a real issue, you need to see how far it’s spread. Is it just one computer, or has it hopped to other machines? This is about drawing a boundary around the problem so you know what you’re dealing with.
Classifying Incident Types
Not all cyber problems are the same. Some are like a minor fender-bender, while others are a full-blown multi-car pile-up. Knowing the type of incident helps you figure out the right way to respond. Is it malware? Someone trying to get in without permission? A data leak? Maybe it’s something internal. Each type needs a slightly different approach, like how you’d handle a lost pet versus a burglary.
Assessing Severity For Appropriate Response
After you know what kind of problem you have, you need to decide how urgent it is. Severity assessment is key to making sure you don’t waste time on small things while a big one is happening. Is sensitive customer data at risk? Are critical business operations down? Or is it a minor annoyance that can wait a bit? You’ll want to look at things like:
- Impact on business operations: How much is this stopping people from doing their jobs?
- Data sensitivity: Is personal or confidential information involved?
- System criticality: Are the affected systems vital for the company to run?
- Potential for spread: Could this get much worse if not handled quickly?
Understanding the severity helps you decide who needs to be involved and how quickly you need to act. It’s about prioritizing your efforts so you can tackle the most dangerous threats first.
This initial identification and assessment phase is super important. Get it wrong, and you might overreact to something minor or, worse, underreact to a serious threat, letting it grow into something much bigger and harder to fix.
Containment Strategies For Incidents
When a security incident is detected, the immediate priority shifts from identification to containment. This phase is all about stopping the bleeding – preventing the threat from spreading further into your network or causing more damage. Think of it like putting out a small fire before it engulfs the whole building. Effective containment minimizes the impact of a breach and buys valuable time for deeper investigation and remediation.
Limiting Incident Spread
Stopping an incident from spreading is key. This involves quick actions to isolate affected systems and prevent lateral movement by attackers. It’s about creating boundaries to keep the problem contained. This might mean blocking specific IP addresses known to be associated with the attack or disabling network services that are being exploited. The goal is to reduce the ‘blast radius’ of the incident.
Isolating Systems And Disabling Accounts
One of the most direct ways to contain an incident is by isolating the compromised systems. This can be done by disconnecting them from the network, either physically or logically. If an attacker has gained access through a specific user account, disabling that account immediately prevents them from using it to move around or cause further harm. This is a critical step, especially when dealing with threats like ransomware or advanced persistent threats where lateral movement is a common tactic. For instance, if an endpoint detection and response (EDR) system flags suspicious activity, isolating that machine is often the first response [0df3].
Network Segmentation And Traffic Blocking
Network segmentation plays a huge role here. By dividing your network into smaller, isolated zones, you can significantly limit how far an attacker can travel if they manage to breach one segment. If an incident occurs in one zone, you can isolate that entire segment without affecting the rest of your operations [92fc]. Blocking malicious traffic at network entry and exit points is also vital. This can involve using firewalls or intrusion prevention systems to stop known bad actors or suspicious communication patterns from entering or leaving your network. This proactive blocking helps prevent the initial compromise or stop data exfiltration.
Eradication And Remediation Activities
Once an incident is contained, the next critical phase is eradication and remediation. This is where we actively remove the threat and fix the underlying issues that allowed it to happen in the first place. It’s not enough to just stop the bleeding; we need to get rid of the infection and heal the wound.
Removing Malicious Artifacts
This step involves hunting down and eliminating any remnants of the attack. Think of it like clearing out a burglar’s tools and any damage they caused. This could mean deleting malware, removing unauthorized files or processes, and cleaning up any backdoors the attackers might have left behind. It’s a thorough process that often requires deep system analysis to make sure nothing is missed. We need to be absolutely sure the threat is gone before moving on.
Patching Vulnerabilities And Correcting Misconfigurations
This is where we address the ‘how’ of the breach. If attackers got in because of an unpatched software flaw or a misconfigured security setting, we have to fix that. This means applying security updates, reconfiguring firewalls, strengthening access controls, or correcting any other setting that created an opening. It’s about closing the doors and windows that were left unlocked. For example, a common issue is leaving default passwords on devices, which is a huge invitation for trouble. We also need to look at things like device hardening to make sure our systems are as robust as possible.
Revoking Compromised Credentials
If an attacker managed to steal or misuse user credentials, those accounts become a major risk. We need to immediately revoke access for any compromised accounts. This usually involves resetting passwords, disabling the account temporarily, or even forcing a re-authentication for all users if the scope is broad. It’s a vital step to prevent attackers from using stolen access to move laterally within the network or to access sensitive data. This is a key part of incident response and helps prevent reinfection.
Recovery And Business Continuity
After the dust settles from an incident, the real work of getting back to normal begins. This phase is all about making sure your business can keep running, even when things are tough, and then getting everything back to how it should be. It’s not just about fixing computers; it’s about keeping the lights on and the services available.
Restoring Systems And Data
This is where you bring everything back online. It starts with getting your IT infrastructure back up and running. Think servers, networks, and all the software that makes your business tick. If you’ve got good backups, this part goes a lot smoother. The goal is to get systems operational again, but it’s also about making sure the data you’re restoring is clean and hasn’t been tampered with. We need to be careful here, especially after something like a ransomware attack, to avoid reinfection. Restoring from secure backups is key.
Ensuring Critical Operations Continue
Sometimes, you can’t get everything back to 100% right away. That’s where business continuity planning comes in. It means having plans in place to keep your most important operations running, even if some systems are down. This might involve using alternate processes or manual workarounds. The focus is on maintaining essential services for your customers and stakeholders. Think about what absolutely has to keep working, no matter what.
Disaster Recovery Planning
Disaster recovery (DR) is a bit broader than just restoring systems after a cyber incident. It’s about having a plan for major disruptions, whether they’re caused by cyberattacks, natural disasters, or other unforeseen events. DR planning involves setting objectives for how quickly systems need to be back online (Recovery Time Objective, or RTO) and how much data loss is acceptable (Recovery Point Objective, or RPO). Regularly testing these plans is super important. You don’t want to find out your DR plan doesn’t work when you actually need it.
Here’s a quick look at what goes into a solid recovery plan:
- Identify Critical Functions: What parts of the business are most important to keep running?
- Develop Contingency Plans: How will you keep those functions going if primary systems fail?
- Establish Recovery Objectives: Define RTO and RPO for different systems.
- Regularly Test Plans: Conduct drills and simulations to validate readiness.
- Document Procedures: Make sure everyone knows their role and what to do.
Getting back to normal after a cyber incident isn’t just about technical fixes. It requires a clear strategy to maintain essential business functions and a robust plan to restore IT operations. The aim is to minimize downtime and ensure the organization can continue serving its customers and stakeholders throughout the recovery process.
When dealing with incidents, especially those involving financial motives, understanding the threat landscape is vital. Organizations need to be aware of tactics like ransomware and phishing to better prepare their defenses and recovery strategies. Learn about cyber threats.
Forensic Investigation And Evidence Preservation
When a security incident happens, figuring out exactly what went down is super important. This is where forensic investigation comes in. It’s all about collecting and carefully looking at digital evidence to piece together the story of an attack. The goal is to understand how it happened, what systems were affected, and what data might have been compromised. This process isn’t just for curiosity; it’s vital for legal proceedings, regulatory reporting, and making sure we can actually fix the problems that allowed the incident to occur in the first place.
Preserving Evidence For Analysis
This is probably the most critical part of the whole forensic process. If you mess up the evidence, it’s useless, and you might as well forget about any legal or regulatory follow-up. It’s like trying to build a case with missing puzzle pieces.
- Maintain Chain of Custody: Keep a detailed record of who handled the evidence, when, and why. This shows the evidence hasn’t been tampered with.
- Use Write-Blockers: These devices prevent any changes from being made to the original storage media, ensuring its integrity.
- Create Forensic Images: Make exact copies of hard drives, memory, and other storage. These images are what you’ll work on, leaving the original evidence untouched.
- Document Everything: Take notes, photos, and videos of the evidence and the collection process. The more documentation, the better.
Proper evidence handling is not just a technical step; it’s a procedural safeguard that underpins the credibility of the entire investigation. Without it, findings can be challenged and dismissed, leaving an organization vulnerable.
Reconstructing Timelines And Attack Vectors
Once the evidence is secured, the real detective work begins. We’re trying to build a clear picture of the attacker’s movements and methods. This involves looking at logs, network traffic, and system activity.
- Log Analysis: Examining system logs, application logs, and security device logs to find patterns and timestamps.
- Network Traffic Analysis: Reviewing captured network packets to understand communication flows and identify suspicious connections.
- Malware Analysis: If malware was involved, understanding its behavior, origin, and purpose.
- Timeline Creation: Putting all the collected data into a chronological order to see the sequence of events.
Tools like Security Information and Event Management (SIEM) platforms can be incredibly helpful here, pulling together data from various sources to make sense of it all. You can find out more about how these systems work for real-time threat detection.
Maintaining Chain Of Custody
I know I mentioned this earlier, but it’s so important it deserves its own section. The chain of custody is the documented trail showing the seizure, custody, control, transfer, analysis, and disposition of evidence. Think of it as the evidence’s resume – it proves where it’s been and who’s been responsible for it.
- Initial Collection: Document who collected the evidence and when.
- Storage: Record where and how the evidence is stored securely.
- Transfer: Log every time the evidence changes hands.
- Analysis: Note who performed analysis and on what copies.
- Disposition: Record what happens to the evidence after the investigation is complete.
This meticulous record-keeping is what makes the evidence admissible in court or regulatory reviews. It’s the backbone of a credible forensic investigation.
Communication Management During Incidents
Effective communication during a cyber incident isn’t just about exchanging information — it’s about reducing misinformation, enabling quick action, and maintaining organizational trust. Poor communication can make an incident spiral, causing confusion or worse, resulting in unintentional leaks or regulatory missteps. This is why organizations need a clear, practical approach for who talks to whom, when, and about what.
Coordinating Internal and External Teams
When a cyber incident hits, multiple groups rush into action. There’s IT, security, executives, legal, and often external partners or vendors. Even the best technical response falls apart if teams work in isolation. Here’s how to keep coordination tight:
- Appoint a communications lead: One person runs point, directing all updates and keeping messaging consistent.
- Use designated secure channels: Email may not be safe if you suspect compromise — consider alternate methods for urgent, sensitive conversations.
- Share only what is known: Don’t speculate or broadcast unverified details, especially outside the response team.
- Loop in partners and vendors if their systems or data could be affected, but don’t reveal more than required by contracts or regulations.
With solid coordination, internal and external groups move together, minimizing overlap and closing gaps that could allow ongoing threats or miscommunications.
Communicating With Leadership and Legal Counsel
Leadership and legal counsel need timely, relevant updates to steer the organization through the storm. Often, top executives are accountable for regulatory decisions and face media scrutiny. The following steps help keep communications focused and useful:
- Provide plain-language summaries rather than technical jargon. Executives should grasp both impact and recommended actions in clear terms.
- Present options for critical decisions, clearly noting risks or compliance implications relevant to each.
- Ask legal counsel to review any customer, regulatory, or media notifications before release.
Regular check-ins — even with little new information — reassure leadership and prevent the rumor mill from filling the vacuum.
Managing Stakeholder and Media Relations
Stakeholders — whether they’re customers, regulators, or the public — may need notification, especially in high-profile events. Mishandled communication can damage trust fast. Consider these guidelines:
- Prepare holding statements in advance, ready for regulatory or media needs. This limits the scramble and reduces errors.
- Only designated spokespersons interact with media or external stakeholders. Consistency is more important than speed.
- Tailor information to the audience: customers want to know if their data is at risk, regulators care about compliance steps, the media may seek broad context.
Here’s a simple table for who communicates with whom during significant incidents:
| Audience | Communicator | Key Message Focus |
|---|---|---|
| Employees | Internal Comms Lead | Situation status, next steps |
| Executive Leadership | Incident Coordinator | Risk, business impact, needs |
| Regulators | Legal/Compliance Officer | Regulatory obligations |
| Customers | Customer Service/PR | Data impact, reassurance |
| Media/Public | PR or Designated Spokesperson | Confirmed facts, recovery timeline |
When communicating about incidents, accuracy and restraint matter more than speed. Every message should support business objectives, which often means protecting reputation and regulatory standing as much as mitigating technical harm. For tips on aligning security goals with business priorities, see Security as an enabler.
Legal And Regulatory Incident Response
When a cyber incident strikes, it’s not just about fixing the technical mess. There’s a whole legal and regulatory side to deal with, and honestly, it can feel like a whole other beast. Ignoring these aspects can lead to hefty fines, lawsuits, and a serious hit to your company’s reputation.
Meeting Notification Obligations
Different laws and regulations, like GDPR or HIPAA, have specific rules about when and how you need to tell people about a data breach. It’s not a one-size-fits-all situation. You’ve got to figure out who needs to know – maybe it’s affected individuals, maybe it’s a regulatory body, or both. The clock usually starts ticking pretty fast after you discover a breach, so having a plan for this is key. Missing these deadlines or not providing the right information can really complicate things. It’s about being transparent, but also about following the rules to avoid bigger problems down the line. You can find more information on data protection controls.
Coordinating With Legal Counsel
Your legal team is going to be your best friend during an incident. They understand the legal landscape and can help you figure out what your obligations are. They’ll guide you on what you can and can’t say publicly, how to handle evidence for potential legal action, and how to communicate with regulators. It’s important to loop them in early. They can help review your incident response plan to make sure it aligns with legal requirements. Think of them as your shield against legal missteps. They’ll also help you understand the implications of decisions made during the response, like whether to pay a ransom or not, which is a huge decision with legal and ethical angles.
Navigating Varying Jurisdictional Requirements
This is where things get really tricky. If your company operates in multiple states or countries, you’re probably dealing with a patchwork of different laws. What’s required in California might be totally different from what’s needed in Europe or Asia. You need to know where your customers are, where your data is stored, and what laws apply to each of those locations. This often means consulting with legal experts who specialize in different regions. It’s a complex puzzle, and getting it wrong can mean facing penalties in multiple places. Keeping track of these different rules requires a solid understanding of your global footprint and regulatory requirements.
Here’s a quick look at some common notification timelines:
| Jurisdiction/Regulation | Typical Notification Timeframe | Affected Parties | Notes |
|---|---|---|---|
| GDPR (EU) | 72 hours of becoming aware | Supervisory Authority, Data Subjects (if high risk) | Strict requirements for personal data breaches. |
| CCPA/CPRA (California) | Reasonable notification, often within 30-60 days | Affected Consumers | Focuses on personal information. |
| HIPAA (US Healthcare) | 60 days of discovery | HHS, Affected Individuals (if >500) | Specific to protected health information. |
It’s easy to get caught up in the technical fight against attackers, but the legal and regulatory fallout can be just as damaging, if not more so. Proactive planning and expert consultation are not optional; they are necessities for responsible incident management.
Post-Incident Review And Improvement
After the dust settles from a cyber incident, the real work of getting smarter begins. It’s not enough to just fix the immediate problem; we need to figure out why it happened and how to stop it from happening again. This phase is all about learning and making things better for the future.
Analyzing Root Causes
This is where we dig deep to find the actual reason the incident occurred. Was it a technical glitch, a human mistake, or something else entirely? We look at everything from system logs and configuration files to user actions and external factors. Identifying the root cause is key to preventing recurrence. Sometimes it’s obvious, like a missing security patch. Other times, it’s more complex, involving a chain of smaller issues that, when combined, created an opening for attackers.
Evaluating Response Effectiveness
Once we know why it happened, we look at how we handled it. Did our incident response plan work as expected? Were our teams quick and coordinated? Were the right people involved at the right times? We assess the speed of detection, containment, and recovery. This isn’t about blame; it’s about understanding what went well and what could have been smoother. Metrics like Mean Time To Detect (MTTD) and Mean Time To Respond (MTTR) are really useful here.
Here’s a quick look at some common metrics:
| Metric | Description |
|---|---|
| Mean Time To Detect (MTTD) | Average time it takes to discover an incident. |
| Mean Time To Respond (MTTR) | Average time it takes to resolve an incident. |
| Containment Time | Time taken to stop an incident from spreading. |
| Recovery Time | Time taken to restore affected systems and data. |
| False Positive Rate | Percentage of alerts that were not actual threats. |
Integrating Lessons Learned For Future Prevention
This is the payoff. All the analysis from the previous steps needs to translate into concrete actions. We update our security policies, refine our technical controls, and improve our training programs. Maybe we need better monitoring tools, or perhaps our communication plan needs a tweak. It’s about making sure that the next time a similar situation arises, we’re even better prepared. This continuous improvement cycle is what builds a stronger, more resilient security posture over time.
The goal of a post-incident review isn’t just to close a ticket; it’s to actively strengthen the organization’s defenses and response capabilities. Every incident, no matter how small, is an opportunity to learn and adapt in the face of evolving threats.
Metrics For Measuring Incident Response
When a cyber incident happens, it’s not just about putting out the fire. We also need to know how well we did it. That’s where metrics come in. They give us a way to look at our response process and see where we’re doing great and where we need to get better. Think of it like a report card for our security team during a crisis.
Mean Time To Detect and Respond
This is a big one. It’s broken down into two parts: Mean Time To Detect (MTTD) and Mean Time To Respond (MTTR). MTTD is how long it takes from when an incident actually starts happening until our systems flag it or our team notices it. MTTR is the time from when we know there’s an incident to when we’ve got it under control or fixed. Shorter times in both categories mean we’re catching and fixing problems faster, which usually means less damage.
- MTTD: Measures the speed of our detection capabilities.
- MTTR: Measures the efficiency of our containment and remediation efforts.
Containment and Recovery Time Metrics
Once we’ve detected an incident, how quickly can we stop it from spreading? That’s containment. We measure how long it takes to isolate affected systems, block malicious traffic, or disable compromised accounts. Then there’s recovery – getting everything back to normal. This includes restoring data, bringing systems back online, and making sure business operations can continue. We track the time it takes for these critical steps to happen.
| Metric Category | Key Performance Indicators |
|---|---|
| Containment | Time to isolate systems |
| Time to block malicious IPs | |
| Recovery | Time to restore data |
| Time to resume operations |
False Positive Rates and Alert Volume
It’s not just about speed; it’s also about accuracy. If our security tools are constantly sending out alerts for things that aren’t actually threats (false positives), our team can get overwhelmed. This leads to alert fatigue, where real threats might get missed because the team is busy sifting through noise. We track the number of false positives and the overall volume of alerts to help tune our systems and make sure our team is focusing on what matters.
- High alert volume can indicate tuning issues or a genuine increase in activity.
- A high false positive rate wastes valuable analyst time.
- Reducing false positives helps focus resources on actual threats.
Measuring these aspects helps us understand the effectiveness of our security tools and the efficiency of our incident response team. It’s not about blame; it’s about continuous improvement so we’re better prepared for the next event.
Moving Forward After an Incident
So, we’ve talked a lot about what to do when things go wrong online. It’s not just about fixing the immediate problem, like getting rid of malware or stopping a data leak. It’s also about learning from it. After the dust settles, taking a good, hard look at what happened is key. Did our tools work? Were our people ready? What could we have done better? This review process helps us get smarter, patch up those gaps we found, and make sure we’re not caught off guard next time. Building a stronger defense isn’t a one-and-done deal; it’s about constantly getting better, adapting to new threats, and making sure our systems can bounce back when needed. It’s a continuous effort, but it’s what keeps us safer in the long run.
Frequently Asked Questions
What is the first thing to do when a cyber incident happens?
When a cyber incident occurs, the very first step is to identify and confirm that it’s a real problem. This means checking if the alerts you’re seeing are accurate and figuring out how widespread the issue is. It’s like checking if a smoke alarm is actually detecting smoke before calling the fire department.
Why is it important to have clear roles during a cyber incident?
Having clear roles, like who’s in charge of what and who to report to, is super important. It stops confusion and makes sure everyone knows exactly what they need to do. This helps the response team act fast and efficiently, like a well-organized sports team.
What does ‘containment’ mean in cyber incident response?
Containment means stopping the cyber problem from spreading further. Think of it like putting up barriers to prevent a fire from reaching other rooms. This could involve disconnecting affected computers or blocking suspicious online activity.
Why do we need to preserve evidence after a cyber incident?
Preserving evidence is crucial because it helps us understand exactly how the attack happened, who did it, and what information might have been affected. This information is vital for fixing the problem, preventing it from happening again, and potentially for legal reasons, like gathering clues for a detective.
What is ‘eradication’ in cyber incident response?
Eradication is all about getting rid of the actual cause of the problem. This means removing any harmful software, fixing security weaknesses, or changing passwords that might have been stolen. It’s like removing the source of an illness so you can get better.
How do organizations recover after a cyber incident?
Recovery involves getting systems and data back to normal. This could mean restoring from backups, fixing damaged systems, and making sure all the important business operations can run smoothly again. It’s about getting things back up and running safely.
What is a ‘post-incident review’ and why is it done?
A post-incident review is like a team debrief after a big event. We look back at what happened, how we responded, what went well, and what could have been better. This helps us learn from the experience and improve our defenses for the future.
What are some key metrics used to measure incident response?
We use metrics to see how good our response is. Some common ones are how quickly we detect a problem (Mean Time To Detect) and how fast we fix it (Mean Time To Respond). These numbers help us understand our strengths and weaknesses.