You've built your ISMS, passed your SOC 2 audit, and locked down your repositories. Then someone on your team forwards a link: a threat actor claims they've dumped your data online. What happens in the next four hours?
These questions arise from real incident response planning sessions with security teams. They're the awkward ones people ask after the formal runbook review, when everyone's wondering if the plan actually works. The Uber Freight incident, where the Helix group claimed to have taken approximately 1 million files, puts these questions front and center. Whether that data proves authentic or not, the organization is now running an investigation into unauthorized access to systems and repositories, living every CISO's nightmare scenario.
Let's answer the questions your team is actually asking.
Do We Really Need Threat Intelligence Feeds?
You don't need a $200K threat intelligence platform. You need a structured way to know what's happening before your customers tell you.
Start with what ISO/IEC 27001:2022 clause 6.1.2(c) requires: determine threats applicable to your information assets. For SOC 2, CC7.2 expects you to identify and respond to changes in risks, which includes understanding the threat landscape relevant to your environment.
Here's what that looks like in practice:
- Subscribe to your infrastructure vendors' security bulletins (AWS Security Bulletins, GitHub Security Advisories, etc.)
- Join the Information Sharing and Analysis Center (ISAC) for your sector if one exists
- Set up Google Alerts for your company name plus "breach" or "leak"
- Monitor public paste sites and breach databases monthly (Have I Been Pwned's domain search is free)
The Google Threat Intelligence Group identified Helix as part of a pattern of threat actors targeting multiple organizations, including Blackstone and Apollo Global Management. You don't need that level of attribution capability. You need to know when repositories in your sector are being targeted so you can check your own access logs.
Budget four hours per month for someone to review these sources and document what you found. That documentation becomes evidence for both your threat assessment and your monitoring control.
Is Our Incident Response Plan Too Long?
No one reads a 47-page plan during an incident. Your auditor knows that.
What you need is a one-page decision tree that answers: Who do I call first? What do I preserve? When do I notify?
ISO/IEC 27001 clause 5.3 requires you to assign responsibilities and authorities for information security roles. During an incident, your plan must clearly state who has authority to make containment decisions, who talks to legal, and who manages external communications. SOC 2 CC7.4 specifically looks at whether you've defined and communicated responsibilities for incident response.
Build your plan in layers:
Layer 1 (one page): Initial responder checklist. If you discover unauthorized access, you need to know within 15 minutes whether to shut down the affected system or leave it running for forensics. That decision tree should fit on a page you can print and tape inside your security team's desks.
Layer 2 (5-10 pages): Role-specific runbooks. Your IR coordinator needs different information than your communications lead. Separate the documents.
Layer 3 (the rest): Reference material, compliance requirements, contact trees, evidence handling procedures. Nobody reads this during the incident. They reference it during the post-incident review.
When Uber Freight started investigating unauthorized access, someone had to decide immediately what to preserve, what to isolate, and who to loop in. That decision-making framework is what you're really building.
How Fast Do We Have to Report a Breach?
It depends on what data was accessed and where your users are.
SOC 2 doesn't prescribe notification timelines, that's between you and your customers based on your contracts. But SOC 2 CC7.4 requires you to have a process for communicating security incidents to internal and external parties, and your auditor will ask for evidence that you followed it.
ISO/IEC 27001 clause 5.2 requires your information security policy to be communicated, which includes incident notification procedures. Clause 16.1.5 specifically addresses response to information security incidents and requires you to assess and decide on the need for escalation.
Here's your decision framework:
Immediate (within hours): If you've confirmed unauthorized access to systems containing personal data and you're subject to GDPR, CCPA, or similar regulations, your legal team needs to be involved immediately. Many regulations start the notification clock when you become aware of the breach, not when you finish investigating.
Rapid (24-72 hours): If the incident could affect service availability or data integrity for customers, your customer notification process should trigger. Check your contracts, many enterprise agreements specify notification windows.
Structured (post-investigation): If you're still determining the scope and authenticity of the breach, document every step of your investigation. When Uber Freight stated they're investigating but haven't confirmed authenticity of the published data, that's the phase they're in. You still need to preserve evidence and document decisions, even before you know the full scope.
What If We Can't Tell What Data Was Accessed?
This scenario is more common than anyone wants to admit.
This is where your logging and monitoring controls become critical. ISO/IEC 27001:2022 Annex A control 8.15 (Logging) requires you to produce, store, and protect logs recording user activities and events. SOC 2 CC7.2 requires you to monitor system components and operate controls to detect security incidents.
If you can't tell what was accessed, you have two problems:
Immediate: Assume the worst-case scenario for notification purposes. If an attacker had access to your repository, treat all data in that repository as potentially compromised.
Systemic: Your logging wasn't sufficient to support incident investigation. That's a control deficiency, and it'll show up in your next audit. Your auditor will test whether your logs actually support incident detection and investigation.
Fix the immediate problem first, then fix the logging. You need detailed access logs for all systems containing sensitive data, retained long enough to support investigation. For most organizations, that means 90 days minimum, with critical systems at one year.
How Do We Test Our IR Plan?
Run a tabletop exercise in your next quarterly security meeting. It takes two hours.
Pick a realistic scenario: "A security researcher contacts us claiming to have found exposed customer data in a misconfigured S3 bucket. They've provided a sample of 50 records. What do we do?" Then walk through your actual plan with the people who'd be involved.
ISO/IEC 27001 clause 16.1.7 requires you to learn from incidents, which includes testing your response capability. SOC 2 CC7.5 expects you to develop and test security incident response plans.
Your auditor will ask for evidence of testing. A tabletop exercise with documented attendees, scenario, decisions made, and improvement actions identified counts as evidence. You don't need to simulate a full breach with hired red teamers (though that's valuable if you can afford it). You need to prove your team knows who does what when things go wrong.
Document three things from every test: What worked? What didn't? What are we changing?
Where Do We Go From Here?
Start with your incident response plan. Open it right now. Can you answer these questions in under two minutes by looking at it?
- Who's authorized to decide whether to take a system offline?
- Where are your investigation logs stored, and who has access?
- What's the notification threshold that triggers customer communication?
If you can't answer those quickly, your plan needs work. Block four hours next week to build that one-page decision tree. Everything else can wait, but that can't.
Your threat intelligence program and IR testing can follow. But when someone forwards you that link claiming your data is out there, you need to know exactly what happens in the next four hours. That's not about compliance, that's about whether your organization can actually respond when it matters.
